From owner-freebsd-hackers@freebsd.org Sun Jun 25 22:10: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 7463AD9B50F for ; Sun, 25 Jun 2017 22:10:04 +0000 (UTC) (envelope-from fabian.freyer@physik.tu-berlin.de) Received: from mail.tu-berlin.de (mail.tu-berlin.de [130.149.7.33]) (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 3ADD67F7D2 for ; Sun, 25 Jun 2017 22:10:04 +0000 (UTC) (envelope-from fabian.freyer@physik.tu-berlin.de) X-tubIT-Incoming-IP: 130.149.50.25 Received: from mail.physik-pool.tu-berlin.de ([130.149.50.25] helo=mail.physik.tu-berlin.de) by mail.tu-berlin.de (exim-4.89/mailfrontend-6) with esmtp for id 1dPFjE-0007v6-3G; Mon, 26 Jun 2017 00:10:01 +0200 Received: from [130.149.50.251] (aufsichtskiste.physik-pool.tu-berlin.de [130.149.50.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.physik.tu-berlin.de (Postfix) with ESMTPSA id E652F19A7 for ; Sun, 25 Jun 2017 22:09:51 +0000 (UTC) To: freebsd-hackers@freebsd.org From: Fabian Freyer Subject: Kernel panic in nfsv4_loadattr X-Enigmail-Draft-Status: N1110 Message-ID: <118188c1-6507-fd83-9d6e-94e304521011@physik.tu-berlin.de> Date: Mon, 26 Jun 2017 00:09:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 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: Sun, 25 Jun 2017 22:10:04 -0000 Hi! I've had a panic on a host mounting NFSv4 shares. There are also jails running on this host acessing these shares (I assume this might be a problem, as I'm also seeing the nfsuserd messages mentioned in [1]). Here's the last relevant lines of the kernel message buffer: -----8< [snip] Jun 25 05:47:39 emmi nfsuserd:[916]: req from ip=0x[REDACTED] port=949 kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0x2418 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80ab5598 stack pointer = 0x28:0xfffffe104bfd4740 frame pointer = 0x28:0xfffffe104bfd47a0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 11790 (pop3) trap number = 12 panic: page fault cpuid = 4 KDB: stack backtrace: #0 0xffffffff80b24477 at kdb_backtrace+0x67 #1 0xffffffff80ad97e2 at vpanic+0x182 #2 0xffffffff80ad9653 at panic+0x43 #3 0xffffffff80fa1d51 at trap_fatal+0x351 #4 0xffffffff80fa1f43 at trap_pfault+0x1e3 #5 0xffffffff80fa14ec at trap+0x26c #6 0xffffffff80f845a1 at calltrap+0x8 #7 0xffffffff80b39cb9 at propagate_priority+0xb9 #8 0xffffffff80b3a99f at turnstile_wait+0x3ef #9 0xffffffff80ad4764 at __rw_wlock_hard+0x94 #10 0xffffffff80d0b0af at udp_disconnect+0x9f #11 0xffffffff80b728cc at soclose+0x3c #12 0xffffffff80d7ce84 at clnt_dg_destroy+0x2f4 #13 0xffffffff80d7deae at clnt_reconnect_call+0x8be #14 0xffffffff80993ead at newnfs_request+0xa6d #15 0xffffffff8099d894 at nfsrv_getuser+0x234 #16 0xffffffff8099b939 at nfsv4_strtogid+0x259 #17 0xffffffff8099a323 at nfsv4_loadattr+0x3713 Uptime: 19d17h29m20s -----8< [snap] I'm a bit unsure as to how to debug this. This is the second time this crash has happened (last time 19 days ago...) so it's somewhat reproducable. I'd be happy about any pointers. Fabian [1] https://lists.freebsd.org/pipermail/freebsd-fs/2016-December/024259.html -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? From owner-freebsd-hackers@freebsd.org Sun Jun 25 22:44: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 4D86CD9BD3C for ; Sun, 25 Jun 2017 22:44:08 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670040.outbound.protection.outlook.com [40.107.67.40]) (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 D8701807E7 for ; Sun, 25 Jun 2017 22:44:07 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.15; Sun, 25 Jun 2017 22:44:05 +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.1199.017; Sun, 25 Jun 2017 22:44:04 +0000 From: Rick Macklem To: Fabian Freyer , "freebsd-hackers@freebsd.org" Subject: Re: Kernel panic in nfsv4_loadattr Thread-Topic: Kernel panic in nfsv4_loadattr Thread-Index: AQHS7f/RaN1TrU4zxEOQTInOX6nteaI2J8uC Date: Sun, 25 Jun 2017 22:44:04 +0000 Message-ID: References: <118188c1-6507-fd83-9d6e-94e304521011@physik.tu-berlin.de> In-Reply-To: <118188c1-6507-fd83-9d6e-94e304521011@physik.tu-berlin.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: physik.tu-berlin.de; dkim=none (message not signed) header.d=none;physik.tu-berlin.de; dmarc=none action=none header.from=uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTXPR01MB0189; 7:y0mE9R/M++W7qOv8+Yer9c93VQM9mXWBoICtHJite7PivvM3a+av+owFRujCm2NbPtxYo7ZW/zS6IB228KlEUmGn6vubCZD2idZ4OyBq5KWQIqBFIAUKfETHWESbq2/kSbCpS9Qrk0winWlUSb5IdVwSaeSXNw8rbWjMlnJHeYJIer2dO5BOomrsanr2gD1DAbfGddkTlOvMXlemkLoIzkVafwQSdVzNEtaSv00Qna3ksr+6yJNCYMDhKmBxrxBYsfdTkLxgnkWh6c//zpG/1y+uKcd8jO0ms6GzacFuDzE2/CZT5obF07LCGOEgZmmgrMpr9nqkzEry9as5kOdTc5QJV2VCD4wZ2lDv0iEvFB6xJXQIjCZPjlqWPeeN7aDy0f7qDg2sdpfTiLb9wX7mulYFCg64V76PdtxaQcnZ2YWI2fuHj2d4JmRCddvz/F1WC2DzSk76SLr0NUIAPqu59kv6Isn33xAw60v8dzrI2fGIf/6xwLpkTfMwvMqRQ84fQZH+Jo/r5Rl3qNIrlX2hjhVqmzGZYdSgRWhA7W8snQMiZ0JkB4fLbZ0RLZ5cVN/s0Ql/CsgH4tdApyOf9s5h6jWJsJruuxlh+92PC6gs/5ya3PFUWFKIqPP7x3vpCf/Y3IUX29VGH+TBa5UdrP6TUP0AgHFMhIFwiNPFeAkc0cGTHpKVxqVN4/8EHJ3TuGRcgEareKUy4jsqYoigWbFS0TH4ximdFtN7cTNEFS2ROIU0DQfdQcsh+jZY/u2wlGWjw0shVDT8zzSK3gFUQUGofMkOuzHo/YbTOE4NY1yXnDM= x-ms-office365-filtering-correlation-id: 840c3d93-c6fa-4674-f8cb-08d4bc1baebf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(49563074)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095); SRVR:YTXPR01MB0189; x-ms-traffictypediagnostic: YTXPR01MB0189: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(236129657087228)(48057245064654)(167848164394848)(247924648384137); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6041248)(20161123564025)(20161123560025)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:YTXPR01MB0189; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:YTXPR01MB0189; x-forefront-prvs: 034902F5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39400400002)(39410400002)(39840400002)(24454002)(6436002)(25786009)(189998001)(122556002)(6246003)(38730400002)(53936002)(33656002)(74482002)(8936002)(2900100001)(9686003)(86362001)(8676002)(81166006)(3660700001)(5660300001)(305945005)(74316002)(7696004)(5890100001)(2501003)(478600001)(14454004)(76176999)(54356999)(102836003)(3280700002)(55016002)(50986999)(2906002)(77096006)(229853002)(6506006)(99936001)(2950100002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0189; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_003_YTXPR01MB0189AEFF9AE549885A1F1373DDDE0YTXPR01MB0189CANP_" MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2017 22:44:04.7256 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0189 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, 25 Jun 2017 22:44:08 -0000 --_003_YTXPR01MB0189AEFF9AE549885A1F1373DDDE0YTXPR01MB0189CANP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Fabian Freyer wrote: > I've had a panic on a host mounting NFSv4 shares. There are also jails > running on this host acessing these shares (I assume this might be a > problem, as I'm also seeing the nfsuserd messages mentioned in [1]). > Here's the last relevant lines of the kernel message buffer. > Jun 25 05:47:39 emmi nfsuserd:[916]: req from ip=3D0x[REDACTED] port=3D94= 9 > kernel trap 12 with interrupts disabled The nfsuserd daemon doesn't work when jails are enabled. (I'm not a jails person, but I understand jails blocks/disables 127.0.0.1 and that will defi= nitely break nfsuserd.) I have a patch that switches nfsuserd to use a local socket to avoid this, = but another tester experienced hangs when using it. I believe the hangs were caused by races in the local socket code tickled by having multiple nfsuser= d daemons running, but since I could not reproduce the hang, I never committe= d the patch to head, etc. (There is PR#205193 for this.) Without the patch, you have three choices: 1 - Set vfs.nfsd.enable_stringtouid=3D1 and don't run the nfsuserd. (This s= hould allow NFSv4 to work, assuming you are not doing Kerberos mounts and your ui= d space is consistent between clients and server.) 2 - Get rid of the jails. 3 - Change all your mounts to NFSv3 and don't try to run the nfsuserd daemo= n. In case you can test the patch, I have attached it. (It is actually 2 patch= es, one for nfsuserd.c and one for the kernel. I don't remember what version of sources= it is done for, but since you didn't mention what version of FreeBSD you are r= unning...) If you test it, make sure to include "1" as the last argument to nfsuserd, = so that it only runs one daemon. - Until someone successfully tests this patch, this problem will probably r= emain, rick [stuff snipped] ps: If you can test it, but have trouble applying the patch, email and I'll= try to update the patch to current sources.= --_003_YTXPR01MB0189AEFF9AE549885A1F1373DDDE0YTXPR01MB0189CANP_ Content-Type: application/octet-stream; name="nfsuserd-aflocal.patch" Content-Description: nfsuserd-aflocal.patch Content-Disposition: attachment; filename="nfsuserd-aflocal.patch"; size=4683; creation-date="Sun, 25 Jun 2017 22:43:23 GMT"; modification-date="Sun, 25 Jun 2017 22:43:23 GMT" Content-Transfer-Encoding: base64 LS0tIHVzci5zYmluL25mc3VzZXJkL25mc3VzZXJkLmMuc2F2CTIwMTUtMTItMDkgMTg6NDY6Mjku Mjg0OTcyMDAwIC0wNTAwCisrKyB1c3Iuc2Jpbi9uZnN1c2VyZC9uZnN1c2VyZC5jCTIwMTUtMTIt MTAgMjE6MzU6MTcuNTA1MzQzMDAwIC0wNTAwCkBAIC0zNSw2ICszNSw3IEBAIF9fRkJTRElEKCIk RnJlZUJTRDogaGVhZC91c3Iuc2Jpbi9uZnN1c2UKICNpbmNsdWRlIDxzeXMvbW91bnQuaD4KICNp bmNsdWRlIDxzeXMvc29ja2V0Lmg+CiAjaW5jbHVkZSA8c3lzL3NvY2tldHZhci5oPgorI2luY2x1 ZGUgPHN5cy9zdGF0Lmg+CiAjaW5jbHVkZSA8c3lzL3RpbWUuaD4KICNpbmNsdWRlIDxzeXMvdWNy ZWQuaD4KICNpbmNsdWRlIDxzeXMvdm5vZGUuaD4KQEAgLTQzLDYgKzQ0LDcgQEAgX19GQlNESUQo IiRGcmVlQlNEOiBoZWFkL3Vzci5zYmluL25mc3VzZQogI2luY2x1ZGUgPG5mcy9uZnNzdmMuaD4K IAogI2luY2x1ZGUgPHJwYy9ycGMuaD4KKyNpbmNsdWRlIDxycGMvcnBjX2NvbS5oPgogCiAjaW5j bHVkZSA8ZnMvbmZzL3JwY3YyLmg+CiAjaW5jbHVkZSA8ZnMvbmZzL25mc3Byb3RvLmg+CkBAIC03 Myw2ICs3NSw5IEBAIHN0YXRpYyBib29sX3QJeGRyX2dldGlkKFhEUiAqLCBjYWRkcl90KTsKIHN0 YXRpYyBib29sX3QJeGRyX2dldG5hbWUoWERSICosIGNhZGRyX3QpOwogc3RhdGljIGJvb2xfdAl4 ZHJfcmV0dmFsKFhEUiAqLCBjYWRkcl90KTsKIAorI2lmbmRlZiBfUEFUSF9ORlNVU0VSRFNPQ0sK KyNkZWZpbmUgX1BBVEhfTkZTVVNFUkRTT0NLCSIvdmFyL3J1bi9uZnN1c2VyZC5zb2NrIgorI2Vu ZGlmCiAjZGVmaW5lCU1BWE5BTUUJCTEwMjQKICNkZWZpbmUJTUFYTkZTVVNFUkQJMjAKICNkZWZp bmUJREVGTkZTVVNFUkQJNApAQCAtMTAzLDE1ICsxMDgsMTUgQEAgbWFpbihpbnQgYXJnYywgY2hh ciAqYXJndltdKQogCXN0cnVjdCBuZnNkX2lkYXJncyBuaWQ7CiAJc3RydWN0IHBhc3N3ZCAqcHdk OwogCXN0cnVjdCBncm91cCAqZ3JwOwotCWludCBzb2NrLCBvbmUgPSAxOwotCVNWQ1hQUlQgKnVk cHRyYW5zcDsKLQl1X3Nob3J0IHBvcnRudW07CisJaW50IG9sZG1hc2ssIHNvY2s7CisJU1ZDWFBS VCAqeHBydDsKIAlzaWdzZXRfdCBzaWduZXc7CiAJY2hhciBob3N0bmFtZVtNQVhIT1NUTkFNRUxF TiArIDFdLCAqY3A7CiAJc3RydWN0IGFkZHJpbmZvICphaXAsIGhpbnRzOwogCXN0YXRpYyB1aWRf dCBjaGVja19kdXBzW01BWFVTRVJNQVhdOwogCWdpZF90IGdycHNbTkdST1VQU107CiAJaW50IG5n cm91cDsKKwlzdHJ1Y3Qgc29ja2FkZHJfdW4gc3VuOwogCiAJaWYgKG1vZGZpbmQoIm5mc2NvbW1v biIpIDwgMCkgewogCQkvKiBOb3QgcHJlc2VudCBpbiBrZXJuZWwsIHRyeSBsb2FkaW5nIGl0ICov CkBAIC0yNDUsNDYgKzI1MCw0MiBAQCBtYWluKGludCBhcmdjLCBjaGFyICphcmd2W10pCiAJZm9y IChpID0gMDsgaSA8IG5mc3VzZXJkY250OyBpKyspCiAJCXNsYXZlc1tpXSA9IChwaWRfdCktMTsK IAotCS8qCi0JICogU2V0IHVwIHRoZSBzZXJ2aWNlIHBvcnQgdG8gYWNjZXB0IHJlcXVlc3RzIHZp YSBVRFAgZnJvbQotCSAqIGxvY2FsaG9zdCAoMTI3LjAuMC4xKS4KLQkgKi8KLQlpZiAoKHNvY2sg PSBzb2NrZXQoQUZfSU5FVCwgU09DS19ER1JBTSwgSVBQUk9UT19VRFApKSA8IDApCi0JCWVycigx LCAiY2Fubm90IGNyZWF0ZSB1ZHAgc29ja2V0Iik7Ci0KLQkvKgotCSAqIE5vdCBzdXJlIHdoYXQg dGhpcyBkb2VzLCBzbyBJJ2xsIGxlYXZlIGl0IGhlcmUgZm9yIG5vdy4KLQkgKi8KLQlzZXRzb2Nr b3B0KHNvY2ssIFNPTF9TT0NLRVQsIFNPX1JFVVNFQUREUiwgJm9uZSwgc2l6ZW9mKG9uZSkpOwot CQotCWlmICgodWRwdHJhbnNwID0gc3ZjdWRwX2NyZWF0ZShzb2NrKSkgPT0gTlVMTCkKLQkJZXJy KDEsICJDYW4ndCBzZXQgdXAgc29ja2V0Iik7Ci0KLQkvKgotCSAqIEJ5IG5vdCBzcGVjaWZ5aW5n IGEgcHJvdG9jb2wsIGl0IGlzIGxpbmtlZCBpbnRvIHRoZQotCSAqIGRpc3BhdGNoIHF1ZXVlLCBi dXQgbm90IHJlZ2lzdGVyZWQgd2l0aCBwb3J0bWFwcGVyLAotCSAqIHdoaWNoIGlzIGp1c3Qgd2hh dCBJIHdhbnQuCi0JICovCi0JaWYgKCFzdmNfcmVnaXN0ZXIodWRwdHJhbnNwLCBSUENQUk9HX05G U1VTRVJELCBSUENORlNVU0VSRF9WRVJTLAotCSAgICBuZnN1c2VyZHNydiwgMCkpCi0JCWVycigx LCAiQ2FuJ3QgcmVnaXN0ZXIgbmZzdXNlcmQiKTsKKwltZW1zZXQoJnN1biwgMCwgc2l6ZW9mIHN1 bik7CisJc3VuLnN1bl9mYW1pbHkgPSBBRl9MT0NBTDsKKwl1bmxpbmsoX1BBVEhfTkZTVVNFUkRT T0NLKTsKKwlzdHJjcHkoc3VuLnN1bl9wYXRoLCBfUEFUSF9ORlNVU0VSRFNPQ0spOworCXN1bi5z dW5fbGVuID0gU1VOX0xFTigmc3VuKTsKKwlzb2NrID0gc29ja2V0KEFGX0xPQ0FMLCBTT0NLX1NU UkVBTSwgMCk7CisJaWYgKHNvY2sgPCAwKQorCQllcnIoMSwgIkNhbid0IGNyZWF0ZSBsb2NhbCBu ZnN1c2VyZCBzb2NrZXQiKTsKKwlvbGRtYXNrID0gdW1hc2soU19JWFVTUiB8IFNfSVJXWEcgfCBT X0lSV1hPKTsKKwlpZiAoYmluZChzb2NrLCAoc3RydWN0IHNvY2thZGRyICopJnN1biwgc3VuLnN1 bl9sZW4pIDwgMCkKKwkJZXJyKDEsICJDYW4ndCBiaW5kIGxvY2FsIG5mc3VzZXJkIHNvY2tldCIp OworCXVtYXNrKG9sZG1hc2spOworCWlmIChsaXN0ZW4oc29jaywgU09NQVhDT05OKSA8IDApCisJ CWVycigxLCAiQ2FuJ3QgbGlzdGVuIG9uIGxvY2FsIG5mc3VzZXJkIHNvY2tldCIpOworCXhwcnQg PSBzdmNfdmNfY3JlYXRlKHNvY2ssIFJQQ19NQVhEQVRBU0laRSwgUlBDX01BWERBVEFTSVpFKTsK KwlpZiAoeHBydCA9PSBOVUxMKQorCQllcnIoMSwgIkNhbid0IGNyZWF0ZSB0cmFuc3BvcnQgZm9y IGxvY2FsIG5mc3VzZXJkIHNvY2tldCIpOworCWlmICghc3ZjX3JlZyh4cHJ0LCBSUENQUk9HX05G U1VTRVJELCBSUENORlNVU0VSRF9WRVJTLCBuZnN1c2VyZHNydiwKKwkgICAgTlVMTCkpCisJCWVy cigxLCAiQ2FuJ3QgcmVnaXN0ZXIgc2VydmljZSBmb3IgbG9jYWwgbmZzdXNlcmQgc29ja2V0Iik7 CiAKIAkvKgotCSAqIFRlbGwgdGhlIGtlcm5lbCB3aGF0IG15IHBvcnQjIGlzLgorCSAqIFRlbGwg dGhlIGtlcm5lbCB3aGF0IHRoZSBzb2NrZXQncyBwYXRoIGlzLgogCSAqLwotCXBvcnRudW0gPSBo dG9ucyh1ZHB0cmFuc3AtPnhwX3BvcnQpOwogI2lmZGVmIERFQlVHCi0JcHJpbnRmKCJwb3J0bnVt PTB4JXhcbiIsIHBvcnRudW0pOworCXByaW50Zigic29ja3BhdGg9JXNcbiIsIF9QQVRIX05GU1VT RVJEU09DSyk7CiAjZWxzZQotCWlmIChuZnNzdmMoTkZTU1ZDX05GU1VTRVJEUE9SVCwgKGNhZGRy X3QpJnBvcnRudW0pIDwgMCkgeworCWlmIChuZnNzdmMoTkZTU1ZDX05GU1VTRVJEUE9SVCB8IE5G U1NWQ19ORVdTVFJVQ1QsIF9QQVRIX05GU1VTRVJEU09DSykKKwkgICAgPCAwKSB7CiAJCWlmIChl cnJubyA9PSBFUEVSTSkgewogCQkJZnByaW50ZihzdGRlcnIsCiAJCQkgICAgIkNhbid0IHN0YXJ0 IG5mc3VzZXJkIHdoZW4gYWxyZWFkeSBydW5uaW5nIik7CiAJCQlmcHJpbnRmKHN0ZGVyciwKIAkJ CSAgICAiIElmIG5vdCBydW5uaW5nLCB1c2UgdGhlIC1mb3JjZSBvcHRpb24uXG4iKTsKLQkJfSBl bHNlIHsKLQkJCWZwcmludGYoc3RkZXJyLCAiQ2FuJ3QgZG8gbmZzc3ZjKCkgdG8gYWRkIHBvcnRc biIpOwotCQl9CisJCX0gZWxzZQorCQkJZnByaW50ZihzdGRlcnIsICJDYW4ndCBkbyBuZnNzdmMo KSB0byBhZGQgc29ja2V0XG4iKTsKIAkJZXhpdCgxKTsKIAl9CiAjZW5kaWYKQEAgLTQ1NSwyOCAr NDU2LDExIEBAIG5mc3VzZXJkc3J2KHN0cnVjdCBzdmNfcmVxICpycXN0cCwgU1ZDWFAKIAlzdHJ1 Y3QgcGFzc3dkICpwd2Q7CiAJc3RydWN0IGdyb3VwICpncnA7CiAJaW50IGVycm9yOwotCXVfc2hv cnQgc3BvcnQ7CiAJc3RydWN0IGluZm8gaW5mbzsKIAlzdHJ1Y3QgbmZzZF9pZGFyZ3MgbmlkOwot CXVfaW50MzJfdCBzYWRkcjsKIAlnaWRfdCBncnBzW05HUk9VUFNdOwogCWludCBuZ3JvdXA7CiAK LQkvKgotCSAqIE9ubHkgaGFuZGxlIHJlcXVlc3RzIGZyb20gMTI3LjAuMC4xIG9uIGEgcmVzZXJ2 ZWQgcG9ydCBudW1iZXIuCi0JICogKFNpbmNlIGEgcmVzZXJ2ZWQgcG9ydCAjIGF0IGxvY2FsaG9z dCBpbXBsaWVzIGEgY2xpZW50IHdpdGgKLQkgKiAgbG9jYWwgcm9vdCwgdGhlcmUgd29uJ3QgYmUg YSBzZWN1cml0eSBicmVhY2guIFRoaXMgaXMgYWJvdXQKLQkgKiAgdGhlIG9ubHkgY2FzZSBJIGNh biB0aGluayBvZiB3aGVyZSBhIHJlc2VydmVkIHBvcnQgIyBtZWFucwotCSAqICBzb21ldGhpbmcu KQotCSAqLwotCXNwb3J0ID0gbnRvaHModHJhbnNwLT54cF9yYWRkci5zaW5fcG9ydCk7Ci0Jc2Fk ZHIgPSBudG9obCh0cmFuc3AtPnhwX3JhZGRyLnNpbl9hZGRyLnNfYWRkcik7Ci0JaWYgKChycXN0 cC0+cnFfcHJvYyAhPSBOVUxMUFJPQyAmJiBzcG9ydCA+PSBJUFBPUlRfUkVTRVJWRUQpIHx8Ci0J ICAgIHNhZGRyICE9IDB4N2YwMDAwMDEpIHsKLQkJc3lzbG9nKExPR19FUlIsICJyZXEgZnJvbSBp cD0weCV4IHBvcnQ9JWRcbiIsIHNhZGRyLCBzcG9ydCk7Ci0JCXN2Y2Vycl93ZWFrYXV0aCh0cmFu c3ApOwotCQlyZXR1cm47Ci0JfQogCXN3aXRjaCAocnFzdHAtPnJxX3Byb2MpIHsKIAljYXNlIE5V TExQUk9DOgogCQlpZiAoIXN2Y19zZW5kcmVwbHkodHJhbnNwLCAoeGRycHJvY190KXhkcl92b2lk LCBOVUxMKSkK --_003_YTXPR01MB0189AEFF9AE549885A1F1373DDDE0YTXPR01MB0189CANP_ Content-Type: application/octet-stream; name="nfsuserd-aflocal-kern.patch" Content-Description: nfsuserd-aflocal-kern.patch Content-Disposition: attachment; filename="nfsuserd-aflocal-kern.patch"; size=4120; creation-date="Sun, 25 Jun 2017 22:43:51 GMT"; modification-date="Sun, 25 Jun 2017 22:43:51 GMT" Content-Transfer-Encoding: base64 LS0tIGZzL25mcy9uZnNfY29tbW9ua3JwYy5jLnNhdgkyMDE1LTEyLTEwIDIwOjAxOjM1LjQ4ODMx NzAwMCAtMDUwMAorKysgZnMvbmZzL25mc19jb21tb25rcnBjLmMJMjAxNS0xMi0xMCAyMDowNDo0 MC45MDM4NTQwMDAgLTA1MDAKQEAgLTE5OCw2ICsxOTgsOCBAQCBuZXduZnNfY29ubmVjdChzdHJ1 Y3QgbmZzbW91bnQgKm5tcCwgc3RyCiAJCQluY29uZiA9IGdldG5ldGNvbmZpZ2VudCgidWRwIik7 CiAJCWVsc2UKIAkJCW5jb25mID0gZ2V0bmV0Y29uZmlnZW50KCJ0Y3AiKTsKKwllbHNlIGlmIChz YWRkci0+c2FfZmFtaWx5ID09IEFGX0xPQ0FMKQorCQluY29uZiA9IGdldG5ldGNvbmZpZ2VudCgi bG9jYWwiKTsKIAllbHNlCiAJCWlmIChucnAtPm5yX3NvdHlwZSA9PSBTT0NLX0RHUkFNKQogCQkJ bmNvbmYgPSBnZXRuZXRjb25maWdlbnQoInVkcDYiKTsKLS0tIGZzL25mcy9uZnNfY29tbW9uc3Vi cy5jLnNhdgkyMDE1LTEyLTEwIDIwOjA5OjI1LjIxODI4MjAwMCAtMDUwMAorKysgZnMvbmZzL25m c19jb21tb25zdWJzLmMJMjAxNS0xMi0xMSAxNzoxNjoxMC45MTI3MTcwMDAgLTA1MDAKQEAgLTMw NDgsNyArMzA0OCw3IEBAIG5mc3J2X2NtcG1peGVkY2FzZSh1X2NoYXIgKmNwLCB1X2NoYXIgKmMK ICAqIFNldCB0aGUgcG9ydCBmb3IgdGhlIG5mc3VzZXJkLgogICovCiBBUFBMRVNUQVRJQyBpbnQK LW5mc3J2X25mc3VzZXJkcG9ydCh1X3Nob3J0IHBvcnQsIE5GU1BST0NfVCAqcCkKK25mc3J2X25m c3VzZXJkcG9ydChzdHJ1Y3Qgc29ja2FkZHIgKnNhZCwgdV9zaG9ydCBwb3J0LCBORlNQUk9DX1Qg KnApCiB7CiAJc3RydWN0IG5mc3NvY2tyZXEgKnJwOwogCXN0cnVjdCBzb2NrYWRkcl9pbiAqYWQ7 CkBAIC0zMDY3LDE2ICszMDY3LDI0IEBAIG5mc3J2X25mc3VzZXJkcG9ydCh1X3Nob3J0IHBvcnQs IE5GU1BST0MKIAkgKi8KIAlycCA9ICZuZnNydl9uZnN1c2VyZHNvY2s7CiAJcnAtPm5yX2NsaWVu dCA9IE5VTEw7Ci0JcnAtPm5yX3NvdHlwZSA9IFNPQ0tfREdSQU07Ci0JcnAtPm5yX3NvcHJvdG8g PSBJUFBST1RPX1VEUDsKLQlycC0+bnJfbG9jayA9IChORlNSX1JFU0VSVkVEUE9SVCB8IE5GU1Jf TE9DQUxIT1NUKTsKIAlycC0+bnJfY3JlZCA9IE5VTEw7Ci0JTkZTU09DS0FERFJBTExPQyhycC0+ bnJfbmFtKTsKLQlORlNTT0NLQUREUlNJWkUocnAtPm5yX25hbSwgc2l6ZW9mIChzdHJ1Y3Qgc29j a2FkZHJfaW4pKTsKLQlhZCA9IE5GU1NPQ0tBRERSKHJwLT5ucl9uYW0sIHN0cnVjdCBzb2NrYWRk cl9pbiAqKTsKLQlhZC0+c2luX2ZhbWlseSA9IEFGX0lORVQ7Ci0JYWQtPnNpbl9hZGRyLnNfYWRk ciA9IGh0b25sKCh1X2ludDMyX3QpMHg3ZjAwMDAwMSk7CS8qIDEyNy4wLjAuMSAqLwotCWFkLT5z aW5fcG9ydCA9IHBvcnQ7CisJcnAtPm5yX2xvY2sgPSAoTkZTUl9SRVNFUlZFRFBPUlQgfCBORlNS X0xPQ0FMSE9TVCk7CisJaWYgKHNhZCAhPSBOVUxMKSB7CisJCS8qIFVzZSB0aGUgQUZfTE9DQUwg c29ja2V0IGFkZHJlc3MgcGFzc2VkIGluLiAqLworCQlycC0+bnJfc290eXBlID0gU09DS19TVFJF QU07CisJCXJwLT5ucl9zb3Byb3RvID0gMDsKKwkJcnAtPm5yX25hbSA9IHNhZDsKKwl9IGVsc2Ug eworCQkvKiBVc2UgdGhlIHBvcnQjIGZvciBhIFVEUCBzb2NrZXQgKG9sZCBuZnN1c2VyZCkuICov CisJCXJwLT5ucl9zb3R5cGUgPSBTT0NLX0RHUkFNOworCQlycC0+bnJfc29wcm90byA9IElQUFJP VE9fVURQOworCQlORlNTT0NLQUREUkFMTE9DKHJwLT5ucl9uYW0pOworCQlORlNTT0NLQUREUlNJ WkUocnAtPm5yX25hbSwgc2l6ZW9mIChzdHJ1Y3Qgc29ja2FkZHJfaW4pKTsKKwkJYWQgPSBORlNT T0NLQUREUihycC0+bnJfbmFtLCBzdHJ1Y3Qgc29ja2FkZHJfaW4gKik7CisJCWFkLT5zaW5fZmFt aWx5ID0gQUZfSU5FVDsKKwkJYWQtPnNpbl9hZGRyLnNfYWRkciA9IGh0b25sKCh1X2ludDMyX3Qp MHg3ZjAwMDAwMSk7CisJCWFkLT5zaW5fcG9ydCA9IHBvcnQ7CisJfQogCXJwLT5ucl9wcm9nID0g UlBDUFJPR19ORlNVU0VSRDsKIAlycC0+bnJfdmVycyA9IFJQQ05GU1VTRVJEX1ZFUlM7CiAJZXJy b3IgPSBuZXduZnNfY29ubmVjdChOVUxMLCBycCwgTkZTUFJPQ0NSRUQocCksIHAsIDApOwotLS0g ZnMvbmZzL25mc192YXIuaC5zYXYJMjAxNS0xMi0xMCAyMDozNjowMS4zNjk1MzYwMDAgLTA1MDAK KysrIGZzL25mcy9uZnNfdmFyLmgJMjAxNS0xMi0xMCAyMDozNjoyMi40NDYyMzcwMDAgLTA1MDAK QEAgLTEyOCw3ICsxMjgsNyBAQCBpbnQgbmZzcnZfY2hlY2tzZXRhdHRyKHZub2RlX3QsIHN0cnVj dCBuCiAgICAgTkZTUFJPQ19UICopOwogaW50IG5mc3J2X2NoZWNrZ2V0YXR0cihzdHJ1Y3QgbmZz cnZfZGVzY3JpcHQgKiwgdm5vZGVfdCwKICAgICBzdHJ1Y3QgbmZzdmF0dHIgKiwgbmZzYXR0cmJp dF90ICosIHN0cnVjdCB1Y3JlZCAqLCBORlNQUk9DX1QgKik7Ci1pbnQgbmZzcnZfbmZzdXNlcmRw b3J0KHVfc2hvcnQsIE5GU1BST0NfVCAqKTsKK2ludCBuZnNydl9uZnN1c2VyZHBvcnQoc3RydWN0 IHNvY2thZGRyICosIHVfc2hvcnQsIE5GU1BST0NfVCAqKTsKIHZvaWQgbmZzcnZfbmZzdXNlcmRk ZWxwb3J0KHZvaWQpOwogdm9pZCBuZnNydl90aHJvd2F3YXlhbGxzdGF0ZShORlNQUk9DX1QgKik7 CiBpbnQgbmZzcnZfY2hlY2tzZXF1ZW5jZShzdHJ1Y3QgbmZzcnZfZGVzY3JpcHQgKiwgdWludDMy X3QsIHVpbnQzMl90ICosCi0tLSBmcy9uZnMvbmZzX2NvbW1vbnBvcnQuYy5zYXYJMjAxNS0xMi0x MCAyMDozNjo1Ni40NjU2NTYwMDAgLTA1MDAKKysrIGZzL25mcy9uZnNfY29tbW9ucG9ydC5jCTIw MTUtMTItMTEgMTc6MTU6MzAuMDI1MzA3MDAwIC0wNTAwCkBAIC00MSw2ICs0MSw3IEBAIF9fRkJT RElEKCIkRnJlZUJTRDogaGVhZC9zeXMvZnMvbmZzL25mc18KICAqLwogI2luY2x1ZGUgPGZzL25m cy9uZnNwb3J0Lmg+CiAjaW5jbHVkZSA8c3lzL3N5c2N0bC5oPgorI2luY2x1ZGUgPHJwYy9ycGNf Y29tLmg+CiAjaW5jbHVkZSA8dm0vdm0uaD4KICNpbmNsdWRlIDx2bS92bV9vYmplY3QuaD4KICNp bmNsdWRlIDx2bS92bV9wYWdlLmg+CkBAIC01MzQsMTEgKzUzNSwzMCBAQCBuZnNzdmNfY2FsbChz dHJ1Y3QgdGhyZWFkICpwLCBzdHJ1Y3QgbmZzCiAJCWdvdG8gb3V0OwogCX0gZWxzZSBpZiAodWFw LT5mbGFnICYgTkZTU1ZDX05GU1VTRVJEUE9SVCkgewogCQl1X3Nob3J0IHNvY2twb3J0OworCQlz dHJ1Y3Qgc29ja2FkZHIgKnNhZDsKKwkJc3RydWN0IHNvY2thZGRyX3VuICpzdW47CiAKLQkJZXJy b3IgPSBjb3B5aW4odWFwLT5hcmdwLCAoY2FkZHJfdCkmc29ja3BvcnQsCi0JCSAgICBzaXplb2Yg KHVfc2hvcnQpKTsKLQkJaWYgKCFlcnJvcikKLQkJCWVycm9yID0gbmZzcnZfbmZzdXNlcmRwb3J0 KHNvY2twb3J0LCBwKTsKKwkJaWYgKCh1YXAtPmZsYWcgJiBORlNTVkNfTkVXU1RSVUNUKSAhPSAw KSB7CisJCQkvKiBOZXcgbmZzdXNlcmQgdXNpbmcgYW4gQUZfTE9DQUwgc29ja2V0LiAqLworCQkJ c3VuID0gbWFsbG9jKHNpemVvZihzdHJ1Y3Qgc29ja2FkZHJfdW4pLCBNX1NPTkFNRSwKKwkJCSAg ICBNX1dBSVRPSyB8IE1fWkVSTyk7CisJCQllcnJvciA9IGNvcHlpbnN0cih1YXAtPmFyZ3AsIHN1 bi0+c3VuX3BhdGgsCisJCQkgICAgc2l6ZW9mKHN1bi0+c3VuX3BhdGgpLCBOVUxMKTsKKwkJCWlm IChlcnJvciAhPSAwKSB7CisJCQkJZnJlZShzdW4sIE1fU09OQU1FKTsKKwkJCQlyZXR1cm4gKGVy cm9yKTsKKwkJCX0KKwkJICAgICAgICBzdW4tPnN1bl9mYW1pbHkgPSBBRl9MT0NBTDsKKwkJICAg ICAgICBzdW4tPnN1bl9sZW4gPSBTVU5fTEVOKHN1bik7CisJCQlzb2NrcG9ydCA9IDA7CisJCQlz YWQgPSAoc3RydWN0IHNvY2thZGRyICopc3VuOworCQl9IGVsc2UgeworCQkJZXJyb3IgPSBjb3B5 aW4odWFwLT5hcmdwLCAoY2FkZHJfdCkmc29ja3BvcnQsCisJCQkgICAgc2l6ZW9mICh1X3Nob3J0 KSk7CisJCQlzYWQgPSBOVUxMOworCQl9CisJCWlmIChlcnJvciA9PSAwKQorCQkJZXJyb3IgPSBu ZnNydl9uZnN1c2VyZHBvcnQoc2FkLCBzb2NrcG9ydCwgcCk7CiAJfSBlbHNlIGlmICh1YXAtPmZs YWcgJiBORlNTVkNfTkZTVVNFUkRERUxQT1JUKSB7CiAJCW5mc3J2X25mc3VzZXJkZGVscG9ydCgp OwogCQllcnJvciA9IDA7Cg== --_003_YTXPR01MB0189AEFF9AE549885A1F1373DDDE0YTXPR01MB0189CANP_-- From owner-freebsd-hackers@freebsd.org Sun Jun 25 23:37: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 B07CED9C7AE for ; Sun, 25 Jun 2017 23:37:42 +0000 (UTC) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Received: from hermes.heuristicsystems.com.au (hermes.heuristicsystems.com.au [203.41.22.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.heuristicsystems.com.au", Issuer "Heuristic Systems Type 4 Host CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CEE2881B1F for ; Sun, 25 Jun 2017 23:37:40 +0000 (UTC) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Received: from [10.0.5.3] (ewsw01.hs [10.0.5.3]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.15.2/8.15.2) with ESMTPSA id v5PNbNLS012299 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 26 Jun 2017 09:37:28 +1000 (AEST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) X-Authentication-Warning: b3.hs: Host ewsw01.hs [10.0.5.3] claimed to be [10.0.5.3] Subject: Re: Kernel panic in nfsv4_loadattr To: Rick Macklem , "freebsd-hackers@freebsd.org" References: <118188c1-6507-fd83-9d6e-94e304521011@physik.tu-berlin.de> From: Dewayne Geraghty Message-ID: <41f2553c-a9a6-f997-4b0a-1fe6c7603835@heuristicsystems.com.au> Date: Mon, 26 Jun 2017 09:37:18 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-AU 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, 25 Jun 2017 23:37:42 -0000 Rick, A minor point. Jails don't break/disable 127.0.0.1, though it certainly changes behaviour. 127.0.0.1 within a jail context is reassigned the first IP that is defined in jail.conf (or passed to the jail during creation). So for example during a ping from a jail with its first ip 10.0.7.96 defined for em1, when a ping occurs within the jail # ping -c 1 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=42 time=0.039 ms the tcpdump of lo0 (from the host system), becomes: 09:16:23.699627 IP 10.0.7.96 > 127.0.0.1: ICMP echo request, id 52014, seq 0, length 64 09:16:23.699671 IP 127.0.0.1 > 10.0.7.96: ICMP echo reply, id 52014, seq 0, length 64 Even though the jail itself has lo0 defined as lo0: flags=8049 metric 0 mtu 16384 options=600003 groups: lo (ie no explicit 127 subnet). This has significant security issues and requires careful firewalling attention. As an aside, a reasonable approach is to define an ip to lo0 (for the jail), then, from a jail with first ip 10.0.7.91 the # ping -c 1 127.0.0.1 becomes 09:25:23.348288 IP 127.1.5.91 > 127.0.0.1: ICMP echo request, id 25647, seq 0, length 64 09:25:23.348319 IP 127.0.0.1 > 127.1.5.91: ICMP echo reply, id 25647, seq 0, length 64 A much better outcome - in terms of not needing to allow a possibly external IP from accessing lo0 :) This may provide further insight into jail/network issues? Cheers. PS Oh and the first IP of a jail also becomes the default route for it From owner-freebsd-hackers@freebsd.org Sun Jun 25 23:47: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 D2123D9C993 for ; Sun, 25 Jun 2017 23:47:04 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670040.outbound.protection.outlook.com [40.107.67.40]) (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 7FF7981ED4 for ; Sun, 25 Jun 2017 23:47:03 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0190.CANPRD01.PROD.OUTLOOK.COM (10.165.218.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.15; Sun, 25 Jun 2017 23:47: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.1199.017; Sun, 25 Jun 2017 23:47:01 +0000 From: Rick Macklem To: Dewayne Geraghty , "freebsd-hackers@freebsd.org" Subject: Re: Kernel panic in nfsv4_loadattr Thread-Topic: Kernel panic in nfsv4_loadattr Thread-Index: AQHS7f/RaN1TrU4zxEOQTInOX6nteaI2J8uCgAAULACAAAEtgw== Date: Sun, 25 Jun 2017 23:47:01 +0000 Message-ID: References: <118188c1-6507-fd83-9d6e-94e304521011@physik.tu-berlin.de> , <41f2553c-a9a6-f997-4b0a-1fe6c7603835@heuristicsystems.com.au> In-Reply-To: <41f2553c-a9a6-f997-4b0a-1fe6c7603835@heuristicsystems.com.au> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: heuristicsystems.com.au; dkim=none (message not signed) header.d=none;heuristicsystems.com.au; dmarc=none action=none header.from=uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTXPR01MB0190; 7:oJhUNaWnKOkNkFrub74DU4jrG+eFkiedcVdpJ99u/lHYLdQRsiEYd8rq1TrGgRUnFryeBGZKTy/NA9XsoUjIud6TpP7MPJ5sR4fBp7QYUIOpYp4PLpXT+ORSq5BlrP/UN18fiCGdv4sfK3MGRT7fnrrpFLmMZDXoHcBCNCoRuLoKWzCnH0ympdapgUeX8H99zoihAXwq9MDzHxZxTw/DtNe26CKdPgIqSqRNvh75OZDOEWjsVzrVQwl9PWlF+wxpweYYJ1dLIBAWG0epwPJHnhRvTuBUZBZ4/O7KKl1uaVJgddiPuX+pASYPmFixtUowwVr7yWgfir2W62tZgHh5CCKuvnAJBqH6cZMw+L6xaT6D653wK997t6xbF+t8jc78aszI6O1f8X6fH2H7EgPM4QdaZR73ziSkXO+REPlgfwbcKUQHP5qXBOxhDgogpuKAmN4OvDYFoXAwZI6FpTFXZ/dq7w4issFYujNlPquyhTLQ0Sb0QjFiHegJ+b0431qT5By4XRUNs6+Y0r4Js+V/uqKe2oTCETdeyt7fwqFUR0VwfWgNiR5AG0esj4iN69R49KJr1LPM/snmt1iEpPvKWTcBVa5BnuJnMzcjVc0rWHFIQR3I1AeumAlKt49e1ty/+XLDyTRgmL5lY05pSHi5qdBzpyBM8WBGJg6eJ9JqRigV15liwT3l2QnfK1+n9Cvly2a+hFxfpWKckmqEhyufNba2e80v0oZx4rexv4hZvNmA3DCN7DrGV4zADUoa2TdVWiGL3b40kJ5PENKy8Sd/u0/Ege+OEP9kp/qDRqlwaZI= x-ms-office365-filtering-correlation-id: 63e5d53c-0285-4dbb-5e86-08d4bc2479cb x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095); SRVR:YTXPR01MB0190; x-ms-traffictypediagnostic: YTXPR01MB0190: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(236129657087228); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6041248)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123564025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:YTXPR01MB0190; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:YTXPR01MB0190; x-forefront-prvs: 034902F5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(39450400003)(39840400002)(39410400002)(39400400002)(24454002)(2501003)(14454004)(8676002)(122556002)(6436002)(7696004)(25786009)(53936002)(76176999)(50986999)(5660300001)(81166006)(3660700001)(478600001)(2906002)(54356999)(189998001)(3280700002)(86362001)(6506006)(2950100002)(8936002)(38730400002)(305945005)(33656002)(55016002)(2900100001)(74482002)(102836003)(229853002)(77096006)(74316002)(9686003)(6246003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0190; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 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: 25 Jun 2017 23:47:01.3516 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0190 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, 25 Jun 2017 23:47:04 -0000 Dewayne Geraghty wrote: > Rick, > A minor point. Jails don't break/disable 127.0.0.1, though it certainly > changes behaviour. > 127.0.0.1 within a jail context is reassigned the first IP that is > defined in jail.conf (or passed to the jail during creation). Ok, well I guess I should say that the change in behaviour for 127.0.0.1 ca= used by a jail breaks the nfsuserd. (The kernel code does an RPC sent over UDP t= o 127.0.0.1 to "upcall" to the nfsuserd daemon.) [good stuff about jails snipped] rick= From owner-freebsd-hackers@freebsd.org Mon Jun 26 07:33: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 ED143DA381F for ; Mon, 26 Jun 2017 07:33:09 +0000 (UTC) (envelope-from ap00@mail.ru) Received: from fallback.mail.ru (fallback10.m.smailru.net [94.100.178.50]) (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 9C21B6ACA7 for ; Mon, 26 Jun 2017 07:33:09 +0000 (UTC) (envelope-from ap00@mail.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Subject:CC:To:Message-ID:From:Date; bh=9stAolLcjxM9N2ujpGec8qrhu8/R7hf3hbYGXYpV2Bs=; b=J1fnBxvM0J36KX2To6M9hpHdsA8nxOWQl1eYp3cC3/GNbyU71Qwjhrx/QH8cSUJrAPIumrYEKDr18E/mN9IyNleEug8yDT4zJSQGqnypFJHQXeb5K1JZuDL6J3ts3O+bKAF+njmnTRMw2ENoIzBqXoMFZgR5Putq+6i8WAk9d/c=; Received: from [10.161.64.53] (port=43830 helo=smtp45.i.mail.ru) by fallback10.m.smailru.net with esmtp (envelope-from ) id 1dPOW3-0002Sm-Lv for freebsd-hackers@freebsd.org; Mon, 26 Jun 2017 10:32:59 +0300 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Subject:CC:To:Message-ID:From:Date; bh=9stAolLcjxM9N2ujpGec8qrhu8/R7hf3hbYGXYpV2Bs=; b=J1fnBxvM0J36KX2To6M9hpHdsA8nxOWQl1eYp3cC3/GNbyU71Qwjhrx/QH8cSUJrAPIumrYEKDr18E/mN9IyNleEug8yDT4zJSQGqnypFJHQXeb5K1JZuDL6J3ts3O+bKAF+njmnTRMw2ENoIzBqXoMFZgR5Putq+6i8WAk9d/c=; Received: from [91.190.121.202] (port=51447 helo=pstation) by smtp45.i.mail.ru with esmtpa (envelope-from ) id 1dPOVu-0008Pz-F3; Mon, 26 Jun 2017 10:32:50 +0300 Date: Mon, 26 Jun 2017 10:32:48 +0300 From: Anthony Pankov X-Priority: 3 (Normal) Message-ID: <18210175522.20170626103248@mail.ru> To: Adrian Chadd CC: "freebsd-hackers@freebsd.org" Subject: Re: using rc.subr only by root restriction In-Reply-To: References: <1599987034.20170623182536@mail.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-7FA49CB5: 0D63561A33F958A5AAE05B6E071A5D117F4BB36BF72BC175CC6B8FF7CF8174AB725E5C173C3A84C3727597FF642BA4D7256FB4D121764FE54E672349037D5FA5C4224003CC836476C0CAF46E325F83A50BF2EBBBDD9D6B0F8DB212830C5B42F72623479134186CDE6BA297DBC24807EABDAD6C7F3747799A X-Mailru-Sender: D8D48EF70163D79D00784CDFC8FD3107552760D774ED4673E56A22638F06347337A118895F133E2350D5CF8590B94F4EC77752E0C033A69E81198BD1A48777B793AC9912533B2342AE208404248635DF X-Mras: OK X-7FA49CB5: 0D63561A33F958A59659FFADB9A45DFAB610131013E1ADDECFDE9DE105D7132C462275124DF8B9C920A5816FF58DF6CF574AF45C6390F7469DAA53EE0834AAEE X-Mailru-Sender: A5480F10D64C900521F65ACE11A97E3D6F92290C323249C20F9E20292745FFF1044891705FD94CA8B26AAFE52D544DF9D50E20E2BC48EF5AA99AB44EAB91793CEAB4BC95F72C04283CDA0F3B3F5B9367 X-Mras: OK 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, 26 Jun 2017 07:33:10 -0000 Hello, > this was my fault. :) Did you mean that you've commited a patch which change the behavior? > There are some limits that you can set as a user. > I think this is a fine change; but I can't speak for the correctness > of using rc.subr as a general library set for your own purposes. :0 At this time I don't think that my patch is a best solutions. First of all I don't see any explanation of ${name}_login_class in rc.subr(8). Silently applying 'daemon' login class to all services seems to be very surprising. I think there are people who modified 'daemon' login class and get a weird result in their system. I know how complex to investigate such things. May be we can agree at "explicit is better than implicit" principle and do not apply a login class when ${name}_login_class is not declared explicity? It will solve my problem too. > On 23 June 2017 at 08:25, Anthony Pankov via freebsd-hackers > wrote: >> Greetings >> >> I was deploying my new system based on FreeBSD 11 and got =D1=84 >> surprise. >> I have specific subsystem which use own startup scripts tied to rc.subr >> for better integration. Those scripts can be used not only by sys= tem startup but also by >> unpriveleged user. >> With FreeBSD 11 in case of unpriveleged user the error appear: "limit= s: >> setrlimit datasize: Operation not permitted" >> >> There is a thread on a forum about the issue: https://forums.freebsd.org= /threads/58304/ >> >> I've never seen a warning to do not use rc.subr in regular scripts so= I >> made it this way. >> >> May be we can consider to patch rc.subr and remove this >> restriction? >> >> >> >> P.S. This patch helps, but may be there is a better way. >> --- /etc/rc.subr.old 2017-06-21 07:11:39.716210000 +0300 >> +++ /etc/rc.subr 2017-06-21 07:18:21.215444000 +0300 >> @@ -1072,7 +1072,9 @@ >> fi >> >> # Prepend default limits >> - _doit=3D"limits -C $_login_class $_doit" >> + if [ `id -u` -eq 0 ]; then >> + _doit=3D"limits -C $_login_class $_doit" >> + fi >> >> # run the full command >> # >> >> >> -- >> >> Anthony Pankov mailto:ap00@mail.ru >> From owner-freebsd-hackers@freebsd.org Mon Jun 26 16:04:33 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 4E9AAD8ADB3 for ; Mon, 26 Jun 2017 16:04:33 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 D848F7E916 for ; Mon, 26 Jun 2017 16:04:32 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wm0-x232.google.com with SMTP id w126so1820528wme.0 for ; Mon, 26 Jun 2017 09:04:32 -0700 (PDT) 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=gtd3pnN8OI12gJUI+nYvEWoqYFy9jOq5ZoLzwX8S31g=; b=HdJKxfXNbuJ5nJotPToYjCB4JVuacgtQn8yZROFrjWQZHjrFFlzsMfvUI2PZjvFwS2 +PXixzX6hzGQO3u86zkc3R9dfrq9LgaJiLnbttSIOfH72o286SdQ6x2mu2xpkFjWJXto gWimike4xtCYDFDRcUTH5B00AyBCHsIkYjUUuZzoihQdEsVjkEJCixJv9BqRK3RSDIwl CqMIlJmQBMN6+W519EEgsEEFlNze3ekpEJFvbhG+SMFvp19drGCbhxNmwSVaobomupG+ /Lej0DPM7kfSDITqCFxB1pCBzwKqvcQDeWyBHdLrLieF4S/WPfUpW9gi/sOrB0Bf4F74 M+JA== 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=gtd3pnN8OI12gJUI+nYvEWoqYFy9jOq5ZoLzwX8S31g=; b=NvtvjLg0Wixx95GjqBPEi0VJBDEViAz3TKgDoDuVBiegAsd4IIvfbj9P1wCSFwRJiD ImYf2S4VFpCwyF8PUYBJQ7jd/OR3Sfj/hh1epDdv1noLMb5irfchPjQYpH+HANog2J8w SB+tiTkwdZktYLd/CXVQQkB/D+jgSMl9Sn/CzSBuSAuHwxGvDHEqmp3rpu1GfsLQUNAa 4+oSY0bK9ACh8fQgfBUpQ6rzKdOSPEg/3GzV7RIEHNKfHH7HYvvwosj3jCWckM3nJDdx 7qfWUdI8H64KUSANz/a//vtnPjTds1U0wWFUgUaXp/zeL1k+9dDv5cp+7oW1xyKl3PwQ 2rPA== X-Gm-Message-State: AKS2vOwZu0K315i19yz2eCryBSoqtYk0viZ5qpe5n1mQem8I/zm1tkT0 tb2GO7+L35FOMd5wjAj0DQO4JBB/QjIs X-Received: by 10.28.166.137 with SMTP id p131mr198858wme.5.1498493070942; Mon, 26 Jun 2017 09:04:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.183.138 with HTTP; Mon, 26 Jun 2017 09:04:30 -0700 (PDT) In-Reply-To: <18210175522.20170626103248@mail.ru> References: <1599987034.20170623182536@mail.ru> <18210175522.20170626103248@mail.ru> From: Adrian Chadd Date: Mon, 26 Jun 2017 09:04:30 -0700 Message-ID: Subject: Re: using rc.subr only by root restriction To: Anthony Pankov Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Mon, 26 Jun 2017 16:15:12 +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: Mon, 26 Jun 2017 16:04:33 -0000 On 26 June 2017 at 00:32, Anthony Pankov wrote: > Hello, > >> this was my fault. :) > > Did you mean that you've commited a patch which change the behavior? > >> There are some limits that you can set as a user. > >> I think this is a fine change; but I can't speak for the correctness >> of using rc.subr as a general library set for your own purposes. :0 > > At this time I don't think that my patch is a best solutions. > > First of all I don't see any explanation of ${name}_login_class in > rc.subr(8). Silently applying 'daemon' login class to all services > seems to be very surprising. I think there are people who modified 'daemon' > login class and get a weird result in their system. I know how > complex to investigate such things. It was supposed to be daemon class. That was the unclear part of it all. If it runs as part of startup, it'd get the daemon class. If you ran it using "service", you got whatever was in the users class. So your daemons would then get the "root" class, and get a LOT more file descriptors, etc. > May be we can agree at "explicit is better than implicit" principle > and do not apply a login class when ${name}_login_class is not > declared explicity? > > It will solve my problem too. No, because the whole point of the services at startup was to actally get the 'daemon' class. That was the intention all along and what happened to things at startup time. My patch was to bring running "service" in line with what the system did at startup time. It sucks - ideally we'd have a service manager that you'd request to run things on your behalf and it'd always apply a consistent set of things, like login class. -adrian From owner-freebsd-hackers@freebsd.org Tue Jun 27 07:20: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 A1538DA3252 for ; Tue, 27 Jun 2017 07:20:50 +0000 (UTC) (envelope-from ap00@mail.ru) Received: from fallback.mail.ru (fallback8.mail.ru [94.100.181.110]) (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 C29257F220 for ; Tue, 27 Jun 2017 07:20:48 +0000 (UTC) (envelope-from ap00@mail.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Subject:CC:To:Message-ID:From:Date; bh=cLsQ3BwQo6b/JHj35wnTwVjFV/lBXiDPM9DhqdWDKr4=; b=F2pUu3Upq3Y10Zcm+dk4GCXKet1UqEGQCWI7jEdqRtjth1mVNOUX8Jj+bE13dqggQeCqmf/K6bv4aPbBC1Fz38FrdC7b4l0RQPUt/t5iMUJrgIqGoVlZWvtUeM0wpJRTHJ9kMP8Yt+dApfjgVXwhx/AVZUO8fkYeRITYXIXvn/M=; Received: from [10.161.64.45] (port=54280 helo=smtp37.i.mail.ru) by fallback8.mail.ru with esmtp (envelope-from ) id 1dPknj-0006F3-CR for freebsd-hackers@freebsd.org; Tue, 27 Jun 2017 10:20:43 +0300 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Subject:CC:To:Message-ID:From:Date; bh=cLsQ3BwQo6b/JHj35wnTwVjFV/lBXiDPM9DhqdWDKr4=; b=F2pUu3Upq3Y10Zcm+dk4GCXKet1UqEGQCWI7jEdqRtjth1mVNOUX8Jj+bE13dqggQeCqmf/K6bv4aPbBC1Fz38FrdC7b4l0RQPUt/t5iMUJrgIqGoVlZWvtUeM0wpJRTHJ9kMP8Yt+dApfjgVXwhx/AVZUO8fkYeRITYXIXvn/M=; Received: from [91.190.121.202] (port=61310 helo=[192.168.192.10]) by smtp37.i.mail.ru with esmtpa (envelope-from ) id 1dPknb-0002GQ-1T; Tue, 27 Jun 2017 10:20:35 +0300 Date: Tue, 27 Jun 2017 10:20:31 +0300 From: Anthony Pankov X-Priority: 3 (Normal) Message-ID: <1352411842.20170627102031@mail.ru> To: Adrian Chadd CC: "freebsd-hackers@freebsd.org" Subject: Re: using rc.subr only by root restriction In-Reply-To: References: <1599987034.20170623182536@mail.ru> <18210175522.20170626103248@mail.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-7FA49CB5: 0D63561A33F958A519ABC1F642B74330A9185D9FA6B0F3C101BD826A951F0E80725E5C173C3A84C3727597FF642BA4D7053618308680E96BDD0078234547CCE7C4224003CC836476C0CAF46E325F83A50BF2EBBBDD9D6B0F8DB212830C5B42F72623479134186CDE6BA297DBC24807EABDAD6C7F3747799A X-Mailru-Sender: D8D48EF70163D79D00784CDFC8FD310767EDC35ECECB5BDC3FF4F25420D6A7C38E40771E925BDC5D50D5CF8590B94F4EC77752E0C033A69E81198BD1A48777B793AC9912533B2342AE208404248635DF X-Mras: OK X-Mras: OK 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, 27 Jun 2017 07:20:50 -0000 >> May be we can agree at "explicit is better than implicit" principle >> and do not apply a login class when ${name}_login_class is not >> declared explicity? >> >> It will solve my problem too. > No, because the whole point of the services at startup was to actally > get the 'daemon' class. That was the intention all along and what > happened to things at startup time. My patch was to bring running > "service" in line with what the system did at startup time. Ok. This was introduced somewhere later then FreeBSD 9.3 and I've missed this. > It sucks - ideally we'd have a service manager that you'd request to > run things on your behalf and it'd always apply a consistent set of > things, like login class. Unfortunately I can't suggest other solution then the proposed patch. The patch introduce an additional logic - service will start not in 'daemon' login class if executed as regular user. But I think this is better then failing with error and eliminating possibility to use rc.subr library in scripts of regular users. May be you'll commit it? -- Anthony From owner-freebsd-hackers@freebsd.org Wed Jun 28 10:27: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 8DD41D9E75F for ; Wed, 28 Jun 2017 10:27:38 +0000 (UTC) (envelope-from kiersb@xs4all.net) Received: from lb2-smtp-cloud3.xs4all.net (lb2-smtp-cloud3.xs4all.net [194.109.24.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "*.xs4all.nl", Issuer "GlobalSign Domain Validation CA - SHA256 - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 377CE73892 for ; Wed, 28 Jun 2017 10:27:37 +0000 (UTC) (envelope-from kiersb@xs4all.net) Received: from peyote3.local ([212.238.162.109]) by smtp-cloud3.xs4all.net with ESMTP id eASP1v00A2MvivG01ASQev; Wed, 28 Jun 2017 12:26:25 +0200 To: freebsd hackers From: Bert Kiers Subject: FreeBSD on NetApp hardware Organization: XS4ALL Message-ID: <3c23fd7b-3e3d-b0e2-d3ae-2a14ef2c7afc@xs4all.net> Date: Wed, 28 Jun 2017 12:26:23 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 28 Jun 2017 10:59:14 +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, 28 Jun 2017 10:27:38 -0000 Hi, We have some abandoned NetApp 6290 hardware and I want to run FreeBSD on it. The original software, OnTap, is also based on FreeBSD. Somebody once told me that is is simple, something like "just change the kernel loader address". Does anyone have more information about this? It would be so cool to run ZFS and bhyve on them :) Meanwhile, I am going to try netboot FreeBSD/amd64 and see how far I get. TIA, -- Bert Kiers, suspected terrorist Love MS-Windows? Must be Stockholm syndrome. From owner-freebsd-hackers@freebsd.org Fri Jun 30 02:12: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 66EA1DAA827 for ; Fri, 30 Jun 2017 02:12:16 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 4EC837BFA6 for ; Fri, 30 Jun 2017 02:12:16 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: by mailman.ysv.freebsd.org (Postfix) id 4DF5EDAA826; Fri, 30 Jun 2017 02:12:16 +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 4D902DAA825 for ; Fri, 30 Jun 2017 02:12:16 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: from mail.michaelwlucas.com (mail.michaelwlucas.com [104.236.197.233]) (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 22FF47BFA5 for ; Fri, 30 Jun 2017 02:12:15 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: from mail.michaelwlucas.com (localhost [127.0.0.1]) by mail.michaelwlucas.com (8.15.2/8.15.2) with ESMTP id v5U2C6fX043626 for ; Thu, 29 Jun 2017 22:12:06 -0400 (EDT) (envelope-from mwlucas@mail.michaelwlucas.com) Received: (from mwlucas@localhost) by mail.michaelwlucas.com (8.15.2/8.15.2/Submit) id v5U2C5x2043625 for hackers@freebsd.org; Thu, 29 Jun 2017 22:12:05 -0400 (EDT) (envelope-from mwlucas) Date: Thu, 29 Jun 2017 22:12:05 -0400 From: "Michael W. Lucas" To: hackers@freebsd.org Subject: extract panic message & debugging from vmcore.0 ? Message-ID: <20170630021205.GA43579@mail.michaelwlucas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.michaelwlucas.com X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mail.michaelwlucas.com [127.0.0.1]); Thu, 29 Jun 2017 22:12:08 -0400 (EDT) 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, 30 Jun 2017 02:12:16 -0000 Hi, Short question: how do I get debug information for a PR from a vmcore? Long question: we have conflicting docs. Which should I follow? Good news: I needed a panic for the new "Absolute FreeBSD" anyway, this one will do. Details: I got an actual kernel panic by running "gpart resize" on: FreeBSD storm 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r318747: Tue May 23 16:27:01 EDT 2017 root@storm:/usr/obj/usr/src/sys/GENERIC amd64 I dumped it at the panic prompt, savecore ran at boot. According to the Handbook, the next step is to run "kgdb kernel.debug vmcore.0" to recover the panic message. But no kgdb is installed. After some searching, I installed devel/gdb. # kgdb kernel.debug /var/crash/vmcore.0 GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD] Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd12.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from kernel.debug...done. ABI doesn't support a vmcore target Well, that's not good. I did more searching and found /usr/src/tools/debugscripts/README. # cd /usr/obj/usr/src/sys/GENERIC # make gdbinit # gdb kernel.debug GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD] Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd12.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from kernel.debug...done. .gdbinit:16: Error in sourced command file: No symbol "remotebaud" in current context. How are we supposed to extract information from a vmcore these days? -- Michael W. Lucas Twitter @mwlauthor nonfiction: https://www.michaelwlucas.com/ fiction: https://www.michaelwarrenlucas.com/ blog: http://blather.michaelwlucas.com/ From owner-freebsd-hackers@freebsd.org Fri Jun 30 02:35: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 D766ADAAEC3 for ; Fri, 30 Jun 2017 02:35:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id BD74E7C7B5 for ; Fri, 30 Jun 2017 02:35:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: by mailman.ysv.freebsd.org (Postfix) id B9879DAAEC2; Fri, 30 Jun 2017 02:35:05 +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 B924EDAAEC1 for ; Fri, 30 Jun 2017 02:35:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (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 6D7767C7B4 for ; Fri, 30 Jun 2017 02:35:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14688 invoked from network); 30 Jun 2017 02:35:03 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 30 Jun 2017 02:35:03 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Thu, 29 Jun 2017 22:35:03 -0400 (EDT) Received: (qmail 9606 invoked from network); 30 Jun 2017 02:35:03 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Jun 2017 02:35:03 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id ABFA2EC7E56; Thu, 29 Jun 2017 19:35:02 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: extract panic message & debugging from vmcore.0 ? From: Mark Millard In-Reply-To: <20170630021205.GA43579@mail.michaelwlucas.com> Date: Thu, 29 Jun 2017 19:35:02 -0700 Cc: hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170630021205.GA43579@mail.michaelwlucas.com> To: "Michael W. Lucas" X-Mailer: Apple Mail (2.3273) 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, 30 Jun 2017 02:35:05 -0000 On 2017-Jun-29, at 7:12 PM, Michael W. Lucas = wrote: > Short question: how do I get debug information for a PR from a vmcore? >=20 > Long question: we have conflicting docs. Which should I follow? >=20 > Good news: I needed a panic for the new "Absolute FreeBSD" anyway, > this one will do. >=20 > Details: >=20 > I got an actual kernel panic by running "gpart resize" on: >=20 > FreeBSD storm 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r318747: Tue May 23 = 16:27:01 EDT 2017 root@storm:/usr/obj/usr/src/sys/GENERIC amd64 >=20 > I dumped it at the panic prompt, savecore ran at boot. According to > the Handbook, the next step is to run "kgdb kernel.debug vmcore.0" to > recover the panic message. But no kgdb is installed. Look for /usr/libexec/kgdb . But for some, most, or all TARGET_ARCH's the FreeBSD folks now recommend using kgdb from ports. (Which you built and installed.) /usr/libexec/kgdb is more for means-of-last-resort use when one can not get to the point of having the port kgdb around. > After some searching, I installed devel/gdb. >=20 > # kgdb kernel.debug /var/crash/vmcore.0 > GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD] > Copyright (C) 2017 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later = > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show = copying" > and "show warranty" for details. > This GDB was configured as "x86_64-portbld-freebsd12.0". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > . > Find the GDB manual and other documentation resources online at: > . > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from kernel.debug...done. > ABI doesn't support a vmcore target >=20 > Well, that's not good. I did more searching and found > /usr/src/tools/debugscripts/README. >=20 > # cd /usr/obj/usr/src/sys/GENERIC > # make gdbinit > # gdb kernel.debug Did you miss a /var/crash/vmcore.0 above? > GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD] > Copyright (C) 2017 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later = > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show = copying" > and "show warranty" for details. > This GDB was configured as "x86_64-portbld-freebsd12.0". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > . > Find the GDB manual and other documentation resources online at: > . > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from kernel.debug...done. > .gdbinit:16: Error in sourced command file: > No symbol "remotebaud" in current context. Unsure about the above. Separately. . . I'm no expert but you might need to pick between the default minidump vs. a full memory dump depending on purposes and what information is to be extracted: debug.minidump: 1 vs. debug.minidump: 0 in the sysctl debug.minidump output. I doubt that they are fully equivalent. Of course a full memory dump implies needing space ready to hold that full copy. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Fri Jun 30 09:07: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 4A0CFD8C812 for ; Fri, 30 Jun 2017 09:07:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (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 F348917F7 for ; Fri, 30 Jun 2017 09:07:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 4590 invoked from network); 30 Jun 2017 09:07:56 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 30 Jun 2017 09:07:56 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Fri, 30 Jun 2017 05:07:56 -0400 (EDT) Received: (qmail 26453 invoked from network); 30 Jun 2017 09:07:56 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Jun 2017 09:07:56 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id AD4B1EC7E56; Fri, 30 Jun 2017 02:07:55 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: head -r320482 vs. TARGET_ARCH=powerpc production style kernel: jumps to non-code and traps (but the debug kernel build works for the same world) Message-Id: <1F24D891-4D11-4623-8183-7F95D9637FB2@dsl-only.net> Date: Fri, 30 Jun 2017 02:07:55 -0700 To: FreeBSD PowerPC ML , FreeBSD Current , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) 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, 30 Jun 2017 09:07:59 -0000 The -r320482 kernel build is via gcc 4.2.1. Both gcc 4.2.1 and clang based worlds show the same problems. TARGET_ARCH=3Dpowerpc64 is not showing the problems. The production kernel build fails but the debug works --each built from the same /usr/src/ tree. I'll note what a normal boot does before getting to the login prompt but after "Starting nfsd." ("Updating motd:" can be mixed in the trap text: not shown below.) I use an example and note a lot about what varies and what stays the same from example boot to example boot of the production kernel. [Manually entered from camera pictures of the screen.] fatal kernel trap exception =3D 0x700 (program) (for "illegal instruction") srr0 =3D 0x70bf878 (note: this varies, for example: 0x5e37230) (note: r0 always matches srr0) (note: ctr always matches srr0) srr1 =3D 0x89032 (stays the same) lr =3D 0x5b7b94 (note: solisten_wakeup+0x4c) (stays the same) curthread =3D 0x5ab8ae0 (varies) pid =3D 920 (varies), comm =3D mountd (stays the same) Tracing command mountd pid 920 tid 100119 (varies) td 0x5ab8ae0 = (varies)(CPU 1) (stack addr range varies) 0xd250a500: at soisconnected+0x21c (at stays the same) 0xd250a540: at unp_connect2+0xf0 (at stays the same) 0xd250a560: at unp_connectat+0x658 (at stays the same) 0xd250a770: at unp_connect+0x2c (at stays the same) 0xd250a790: at uipc_connect+0xc0 (at stays the same) 0xd250a7d0: at soconnectat+0xa0 (at stays the same) 0xd250a800: at soconnect+0x2c (at stays the same) 0xd250a820: at kern_connect+0134 (at stays the same) 0xd250a870: at sys_connect+0x64 (at stays the same) 0xd250a8b0: at trap+0x638 (at stays the same) 0xd250aa50: at powerpc_interrupt+0x1a0 (at stays the same) 0xd250aa80: at user SC trap (at stays the same) by 0x419db168 (stays the same) srr1=3D0xf032 (stays the same) r1 =3D0xffffd5e0 (stays the same) cr =3D0x24440840 (stays the same) xer =3D0x20000000 (stays the same) ctr =3D0x419db160 (stays the same) 005b7b48 stwu r1,-32(r1) 005b7b4c mflr r0 005b7b50 stw r29,20(r1) 005b7b54 stw r30,24(r1) 005b7b58 stw r31,28(r1) 005b7b5c stw r0,36(r1) 005b7b60 mr r31,r1 005b7b64 bcl- 20,4*cr7+so,005b7b68 = 005b7b68 mflr r30 005b7b6c lwz r0,-36(r30) 005b7b70 add r30,r0,r30 005b7b74 mr r29,r3 005b7b78 lwz r0,232(r3) 005b7b7c cmpwi cr7,r0,0 005b7b80 beq- cr7,005b7b98 = 005b7b84 lwz r4,236(r3) 005b7b88 li r5,1 005b7b8c mtctr r0 005b7b90 bctrl lr: 005b7b94 b 005b7bb4 . . . Apparently this means that sol->sol_upcall is not pointing to code at all yet is not null. Given the variability observed, it might be uninitialized --or sol itself is junk. . . void solisten_wakeup(struct socket *sol) { =20 if (sol->sol_upcall !=3D NULL) (void )sol->sol_upcall(sol, sol->sol_upcallarg, = M_NOWAIT); else { selwakeuppri(&sol->so_rdsel, PSOCK); KNOTE_LOCKED(&sol->so_rdsel.si_note, 0); } SOLISTEN_UNLOCK(sol); wakeup_one(&sol->sol_comp); } =20 005b8548 li r10,1 005b854c b 005b8558 005b8550 stwcx. r10,0,r9 005b8554 li r10,0 005b8558 cmpwi cr7,r10,0 005b855c bne- cr7,005b8568 = 005b8560 addi r3,r28,16 005b8564 bl 004d4218 <__mtx_unlock_sleep> 005b8568 mr r3,r27 at soisconnected+0x21c: 005b856c bl 005b7b48 005b8570 b 005b89f0 . . . void soisconnected(struct socket *so) { struct socket *head; . . . restart: =20 SOCK_LOCK(so); if ((head =3D so->so_listen) !=3D NULL && __predict_false(SOLISTEN_TRYLOCK(head) =3D=3D 0)) { SOCK_UNLOCK(so); goto restart; } =20 so->so_state &=3D = ~(SS_ISCONNECTING|SS_ISDISCONNECTING|SS_ISCONFIRMING); so->so_state |=3D SS_ISCONNECTED; if (head !=3D NULL && (so->so_qstate =3D=3D SQ_INCOMP)) { again: if ((so->so_options & SO_ACCEPTFILTER) =3D=3D 0) { TAILQ_REMOVE(&head->sol_incomp, so, so_list); head->sol_incqlen--; TAILQ_INSERT_TAIL(&head->sol_comp, so, so_list); head->sol_qlen++; so->so_qstate =3D SQ_COMP; SOCK_UNLOCK(so); solisten_wakeup(head); /* unlocks */ . . . =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Fri Jun 30 16:36:28 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 D4A83D95982 for ; Fri, 30 Jun 2017 16:36:28 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id BB0EE74B73 for ; Fri, 30 Jun 2017 16:36:28 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: by mailman.ysv.freebsd.org (Postfix) id B9D90D95981; Fri, 30 Jun 2017 16:36:28 +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 B8F42D95980 for ; Fri, 30 Jun 2017 16:36:28 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: from mail.michaelwlucas.com (mail.michaelwlucas.com [104.236.197.233]) (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 7C39D74B72 for ; Fri, 30 Jun 2017 16:36:28 +0000 (UTC) (envelope-from mwlucas@mail.michaelwlucas.com) Received: from mail.michaelwlucas.com (localhost [127.0.0.1]) by mail.michaelwlucas.com (8.15.2/8.15.2) with ESMTP id v5UGaP6o050415; Fri, 30 Jun 2017 12:36:26 -0400 (EDT) (envelope-from mwlucas@mail.michaelwlucas.com) Received: (from mwlucas@localhost) by mail.michaelwlucas.com (8.15.2/8.15.2/Submit) id v5UGaP36050414; Fri, 30 Jun 2017 12:36:25 -0400 (EDT) (envelope-from mwlucas) Date: Fri, 30 Jun 2017 12:36:25 -0400 From: "Michael W. Lucas" To: Mark Millard Cc: hackers@freebsd.org Subject: Re: extract panic message & debugging from vmcore.0 ? Message-ID: <20170630163625.GB50380@mail.michaelwlucas.com> References: <20170630021205.GA43579@mail.michaelwlucas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.michaelwlucas.com X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mail.michaelwlucas.com [127.0.0.1]); Fri, 30 Jun 2017 12:36:26 -0400 (EDT) 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, 30 Jun 2017 16:36:28 -0000 On Thu, Jun 29, 2017 at 07:35:02PM -0700, Mark Millard wrote: > Look for /usr/libexec/kgdb . > > But for some, most, or all TARGET_ARCH's the > FreeBSD folks now recommend using kgdb from > ports. (Which you built and installed.) > > /usr/libexec/kgdb is more for means-of-last-resort > use when one can not get to the point of having > the port kgdb around. Thanks for the info! Seriously. ... > > Well, that's not good. I did more searching and found > > /usr/src/tools/debugscripts/README. > > > > # cd /usr/obj/usr/src/sys/GENERIC > > # make gdbinit > > # gdb kernel.debug > > Did you miss a /var/crash/vmcore.0 above? Same error with and without /var/crash/vmcore.0 Looks what I really need is crashinfo(8). Which isn't referenced... anywhere, far as I can tell. (That's ok, someone will read the book and update the Handbook. ;-) > Separately. . . > > I'm no expert but you might need to pick > between the default minidump vs. a full > memory dump depending on purposes and what > information is to be extracted: > > debug.minidump: 1 > vs. > debug.minidump: 0 > > in the sysctl debug.minidump output. I > doubt that they are fully equivalent. > > Of course a full memory dump implies > needing space ready to hold that full > copy. Again, thanks for that info! ==ml -- Michael W. Lucas Twitter @mwlauthor nonfiction: https://www.michaelwlucas.com/ fiction: https://www.michaelwarrenlucas.com/ blog: http://blather.michaelwlucas.com/ From owner-freebsd-hackers@freebsd.org Fri Jun 30 19:11: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 21657D9879B for ; Fri, 30 Jun 2017 19:11:49 +0000 (UTC) (envelope-from xavinux@gmail.com) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 D344279566 for ; Fri, 30 Jun 2017 19:11:48 +0000 (UTC) (envelope-from xavinux@gmail.com) Received: by mail-qt0-x231.google.com with SMTP id 32so106574839qtv.1 for ; Fri, 30 Jun 2017 12:11:48 -0700 (PDT) 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=o5QCKXWEWKAlZlrt/Nrm1P4WSKws0VUIRTBAMNwT8yo=; b=KbrlkNpMnCJi9+fYXMR3Wk77eTECZcVKqusYv6OjMh/ieyvpPj1c+1YLhzQwqIQZ61 ScVSW1Yo/QP+LFbRDjc+4hss3MIxpwboYX0sw1YyakbIcaM6WZqohgYb4P7m0w2nHY34 w4m9AHhgnLh6m2uBSo0I+g5w/svK4gIeAMSk3dBWWK+Wvc4GJBhZrfVhHpvmmsHfTF4B 4j26Vy60KQEWsSipFEyNOUTsWqC0/PzI+u/tzHwgw+eDC2G5Y1jT5YABXwLlVQz3W94A OMBuZJJUqpM75hSYXnRltuscOGG3UVyQHG7p+FTBj89tjM8vxUQkAYplgrDcPi+K5hkQ VCPA== 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=o5QCKXWEWKAlZlrt/Nrm1P4WSKws0VUIRTBAMNwT8yo=; b=N2kKcRQ7Jrk7HYj6dm8F2rEaYo5HEkU1cj69iUh4FSf3cBIFYFWKr+vBrZ8dAm4UgD 14RryiOpxX4BH1cCx8qJf8C1Gp+xV8YV9P7ysuTbSYDZwDD10ym3grS+3y0WT7GMF58g uExmj6zRwkt9nubFnI7qPYfy1CZhpUFZ5F9CkpgoXftKvNbYRlPCTKJCeOLhna5hvboA NVc/esGeYuVo5Ri9JYcF2gLfIQf8nsDd8gAJIQUyOEIcv8J4XeRaIqkCHpRB++V7m4xK SswiprPfXdBeenJBHxW0OHRNy+Zd6dn93MLau0vtaAwd5EqQYGc5XqaiCtD7U49uOCYF l7Xw== X-Gm-Message-State: AKS2vOwotuvF1pMwzPmK3o1Ps/by+DVaL8K+vso7eGOPoM6yEWweTZRS bN2pKLg7IDhpmhNAkkoW+gzPsgMYNe8blLk= X-Received: by 10.200.47.201 with SMTP id m9mr29955528qta.187.1498849907661; Fri, 30 Jun 2017 12:11:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.163.33 with HTTP; Fri, 30 Jun 2017 12:11:47 -0700 (PDT) From: Javier Romero Date: Fri, 30 Jun 2017 16:11:47 -0300 Message-ID: Subject: Contribution to FreeBSD. 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, 30 Jun 2017 19:11:49 -0000 Hi People, Hope everything is fine there. My name is Javier, live in Buenos Aires, Argentina, and work in the Network Operations Center of an Internet service provider as a Server Sysadmin. I think can start my contribution to FreeBSD as a beta tester and reporting bugs. If you think I could be useful, please let me know how to start working on this. Thank you very much for your kind attention and sorry for the inconvenience. Best Regards, *Javier Romero* *E-mail: xavinux@gmail.com * *Skype: xavinux* From owner-freebsd-hackers@freebsd.org Fri Jun 30 21:40: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 281C1D9B136 for ; Fri, 30 Jun 2017 21:40:25 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm28-vm1.bullet.mail.ne1.yahoo.com (nm28-vm1.bullet.mail.ne1.yahoo.com [98.138.91.35]) (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 E66D57DBAD for ; Fri, 30 Jun 2017 21:40:24 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1498858710; bh=Ua/tbjRIwEftQNxLS97h+3aPujNa1UJpXU+HNkfjaO8=; h=From:Subject:To:Cc:Date:From:Subject; b=l7SNeuKRVgjN6IS3bxlSkP2ABmJk4lGuUpdAUPQV5/a0kH85XItBi6RDOZ1sQ9e3PUa4n9iE7Rg5Sx30VPcjk6MY8lWPuvRA/rN5PYe+nRgOPTGdZrGglYcJjHHFAHReKoCSzpeTNFelafJV0ISmnnRTG4BkYr2/fQVcU7UeoY+KJ09G9OqOAeoRJsxVDa4Oe12US+MzNN9hoRfRxBMz4D4paEgeq8q+GG2N//q1982/yaDIGLznYP/dWetTG+rArMcUmt0dfz3oM82DUvroDmhNsYlhNws60O6Qgw4ICVvlLu7ERZlfHfUDtvnhNWrfa03LnRV5FiK3lcUpfE5ISA== Received: from [98.138.100.118] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 30 Jun 2017 21:38:30 -0000 Received: from [98.138.84.46] by tm109.bullet.mail.ne1.yahoo.com with NNFMP; 30 Jun 2017 21:38:30 -0000 Received: from [127.0.0.1] by smtp114.mail.ne1.yahoo.com with NNFMP; 30 Jun 2017 21:38:30 -0000 X-Yahoo-Newman-Id: 321116.31048.bm@smtp114.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: t9nfrgQVM1kh46aTj1s._qP6Ma.qSFg4UknMHRqp_ET.2i0 DP.LpT2VRTOdDLzu3.uWUAOP3rEvO6a1QhseGXJkM6Y1Fg51.wCQ8IBJ4_6K 6m37J8FbYeVhUll_sft4vbNzZZAihpbMEiV3YvEmxxIxiyMWLJ1fSXh2_pmO eCQgj6rxR4uSjgcdgvD5FB.UP1M9kWl6Hz9Lpr285amN4Pp14mAL3qy1dKEG nGplZ5QmbQRdFE9pRpnZCymFwpn6KLmPKWVtRePvsSAmh9nq54oGPThETSXQ 3mek58WAjUXOweU6za4Syj0UBiH.oKxZiRccQB7zmXgTl_SUAqHU0tIxj1i4 6qvEBR3JKvtIZZU3TRftQYVbVmwoQ.ptQ7WTKRFXEvsVPHuFuvczH5Lb0b40 Wi3LEKamGTt.9g6d_pFM6kYk5vq3yN1sm.p37rIamrG5GZ3tl4zjQIFFSfkf .oSTitJ7QheN1OKWsNJPzMK23zneD9sZSF3rzyvIKeef.m25E7OegcqOiZEq ZdvdAjFO_SJjEQ5prevU- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf From: Pedro Giffuni Subject: Re: Contribution to FreeBSD. Organization: FreeBSD Project To: Javier Romero Cc: FreeBSD Hackers Message-ID: Date: Fri, 30 Jun 2017 16:38:30 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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, 30 Jun 2017 21:40:25 -0000 Hi Javier; > Hi People, > > Hope everything is fine there. > > My name is Javier, live in Buenos Aires, Argentina, and work in the Network > Operations Center of an Internet service provider as a Server Sysadmin. > > I think can start my contribution to FreeBSD as a beta tester and reporting > bugs. > > If you think I could be useful, please let me know how to start working on > this. You could get an image for the 11.1-Prerelease: https://download.freebsd.org/ftp/snapshots/ And after proper setup, and fun, you may try it in production. FreeBSD is pretty mature but we always welcome further insight. Pedro. From owner-freebsd-hackers@freebsd.org Fri Jun 30 22:27: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 76B7BD9C83B for ; Fri, 30 Jun 2017 22:27:12 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mailout.stack.nl (mailout05.stack.nl [IPv6:2001:610:1108:5010::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 462C981039 for ; Fri, 30 Jun 2017 22:27:12 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mailout.stack.nl (Postfix) with ESMTP id A7E5E76; Sat, 1 Jul 2017 00:27:09 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 90A1E28497; Sat, 1 Jul 2017 00:27:09 +0200 (CEST) Date: Sat, 1 Jul 2017 00:27:09 +0200 From: Jilles Tjoelker To: Anthony Pankov Cc: freebsd-hackers@freebsd.org Subject: Re: using rc.subr only by root restriction Message-ID: <20170630222709.GA74602@stack.nl> References: <1599987034.20170623182536@mail.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1599987034.20170623182536@mail.ru> 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, 30 Jun 2017 22:27:12 -0000 On Fri, Jun 23, 2017 at 06:25:36PM +0300, Anthony Pankov via freebsd-hackers wrote: > I was deploying my new system based on FreeBSD 11 and got ф > surprise. I have specific subsystem which use own startup scripts tied > to rc.subr for better integration. Those scripts can be used not > only by system startup but also by unpriveleged user. With FreeBSD > 11 in case of unpriveleged user the error appear: "limits: setrlimit > datasize: Operation not permitted" > There is a thread on a forum about the issue: > https://forums.freebsd.org/threads/58304/ > I've never seen a warning to do not use rc.subr in regular scripts > so I made it this way. > May be we can consider to patch rc.subr and remove this > restriction? > P.S. This patch helps, but may be there is a better way. > --- /etc/rc.subr.old 2017-06-21 07:11:39.716210000 +0300 > +++ /etc/rc.subr 2017-06-21 07:18:21.215444000 +0300 > @@ -1072,7 +1072,9 @@ > fi > > # Prepend default limits > - _doit="limits -C $_login_class $_doit" > + if [ `id -u` -eq 0 ]; then > + _doit="limits -C $_login_class $_doit" > + fi > > # run the full command > # I don't like that this starts id -u many times during startup. Perhaps you can use the id invocation in the code block that unsets $_user if running as that user. By the way, that code block seems to indicate that it was definitely supposed to work to use rc.subr without root privileges. The concern about resource limits and other context not matching normal boot is valid, though. -- Jilles Tjoelker From owner-freebsd-hackers@freebsd.org Sat Jul 1 00:06: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 EF1BAD9E2C8 for ; Sat, 1 Jul 2017 00:06:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (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 A8E1A837C2 for ; Sat, 1 Jul 2017 00:06:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14351 invoked from network); 1 Jul 2017 00:05:58 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 1 Jul 2017 00:05:58 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Fri, 30 Jun 2017 20:05:58 -0400 (EDT) Received: (qmail 23420 invoked from network); 1 Jul 2017 00:05:58 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 1 Jul 2017 00:05:58 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 5280AEC893D; Fri, 30 Jun 2017 17:05:57 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: head -r320482 (e.g.): DNINIT_ALL and SOCK_MAXADDRLEN vs. SOCK_MAXADDRLEN+1 use in char buf[] declarations: is the usage all correct? Message-Id: <3390B896-622E-4548-B483-5772AB3ABD0C@dsl-only.net> Date: Fri, 30 Jun 2017 17:05:56 -0700 To: freebsd-hackers@freebsd.org, FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3273) 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, 01 Jul 2017 00:06:06 -0000 While trying to track down a repeatable crash for powerpc production kernel's (but not debug ones) I ran into the following. (I'm not familiar with the material involved.) NDINIT_ALL in /usr/src/sys/kern/vfs_lookup.c records its char* namep argument in ndp->ni_dirp : /usr/src/sys/kern/uipc_usrreq.c: char buf[SOCK_MAXADDRLEN]; . . . NDINIT_ATRIGHTS(&nd, LOOKUP, FOLLOW | LOCKSHARED | LOCKLEAF, UIO_SYSSPACE, buf, fd, cap_rights_init(&rights, = CAP_CONNECTAT), td); . . . (elsewhere:) void NDINIT_ALL(struct nameidata *ndp, u_long op, u_long flags, enum uio_seg = segflg, const char *namep, int dirfd, struct vnode *startdir, cap_rights_t = *rightsp, struct thread *td) { ndp->ni_cnd.cn_nameiop =3D op; ndp->ni_cnd.cn_flags =3D flags; ndp->ni_segflg =3D segflg; ndp->ni_dirp =3D namep; ndp->ni_dirfd =3D dirfd; ndp->ni_startdir =3D startdir; if (rightsp !=3D NULL) ndp->ni_rightsneeded =3D *rightsp; else cap_rights_init(&ndp->ni_rightsneeded); filecaps_init(&ndp->ni_filecaps); ndp->ni_cnd.cn_thread =3D td; } But the size of the buffer supplied in other calls varies from the size used for this call: /usr/src/sys/fs/nfsclient/nfs_clvfsops.c: if = (args.addrlen > SOCK_MAXADDRLEN) { /usr/src/sys/kern/uipc_syscalls.c: if (len > SOCK_MAXADDRLEN) /usr/src/sys/kern/uipc_usrreq.c: char buf[SOCK_MAXADDRLEN]; /usr/src/sys/netgraph/ng_ksocket.c: if (pathlen > = SOCK_MAXADDRLEN) { /usr/src/sys/netgraph/ng_ksocket.c: char = pathbuf[SOCK_MAXADDRLEN + 1]; /usr/src/sys/sys/socket.h:#define SOCK_MAXADDRLEN 255 = /* longest possible addresses */ Some of the other usage of SOCK_MAXADDRLEN is: if (vfs_getopt(mp->mnt_optnew, "addr", (void **)&args.addr, &args.addrlen) =3D=3D 0) { if (args.addrlen > SOCK_MAXADDRLEN) { error =3D ENAMETOOLONG; goto out; } nam =3D malloc(args.addrlen, M_SONAME, = M_WAITOK); bcopy(args.addr, nam, args.addrlen); nam->sa_len =3D args.addrlen; . . . if (len > SOCK_MAXADDRLEN) return (ENAMETOOLONG); if (len < offsetof(struct sockaddr, sa_data[0])) return (EINVAL); sa =3D malloc(len, M_SONAME, M_WAITOK); . . . if ((path =3D ng_get_string_token(s, off, &toklen, = NULL)) =3D=3D NULL) return (EINVAL); pathlen =3D strlen(path); if (pathlen > SOCK_MAXADDRLEN) { free(path, M_NETGRAPH_KSOCKET); return (E2BIG); } if (*buflen < pathoff + pathlen) { free(path, M_NETGRAPH_KSOCKET); return (ERANGE); } *off +=3D toklen; bcopy(path, sun->sun_path, pathlen); That last suggests that pathlen does not include a '\0' termination character position but that path is supposed to be '\0' terminated (in order to justify strlen(.) use) yet the later bcopy avoids the '\0' position for sun->sun_path. This makes it unclear which of the following is more appropriate vs. if each is correct for its specific usage: /usr/src/sys/kern/uipc_usrreq.c: . . . char buf[SOCK_MAXADDRLEN]; . . . NDINIT_ATRIGHTS(&nd, LOOKUP, FOLLOW | LOCKSHARED | LOCKLEAF, UIO_SYSSPACE, buf, fd, cap_rights_init(&rights, = CAP_CONNECTAT), td); (The above buf has an odd number of bytes.) (The above code is in the execution sequence that leads to the powerpc fatal trap.) /usr/src/sys/netgraph/ng_ksocket.c: . . . case PF_LOCAL: { const int pathoff =3D OFFSETOF(struct sockaddr_un, = sun_path); const struct sockaddr_un *sun =3D (const struct = sockaddr_un *)sa; const int pathlen =3D sun->sun_len - pathoff; char pathbuf[SOCK_MAXADDRLEN + 1]; char *pathtoken; bcopy(sun->sun_path, pathbuf, pathlen); if ((pathtoken =3D ng_encode_string(pathbuf, pathlen)) = =3D=3D NULL) return (ENOMEM); slen +=3D snprintf(cbuf, cbuflen, "local/%s", = pathtoken); free(pathtoken, M_NETGRAPH_KSOCKET); if (slen >=3D cbuflen) return (ERANGE); *off +=3D sun->sun_len; return (0); } =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Sat Jul 1 01:33: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 30074DA04E9; Sat, 1 Jul 2017 01:33:09 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 C46DEEC0; Sat, 1 Jul 2017 01:33:08 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190d-d83ff7000000498b-62-5956fa9ef05c Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 5C.4C.18827.E9AF6595; Fri, 30 Jun 2017 21:27:59 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v611RwHC025080; Fri, 30 Jun 2017 21:27:58 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v611RqN8022900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 30 Jun 2017 21:27:57 -0400 Date: Fri, 30 Jun 2017 20:27:52 -0500 From: Benjamin Kaduk To: freebsd-hackers@FreeBSD.org Cc: freebsd-current@FreeBSD.org Subject: Final Call for 2017Q2 Quarterly Status Reports Message-ID: <20170701012751.GN68391@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qlTNgmc+xy1dBmNv" Content-Disposition: inline User-Agent: Mutt/1.7.1 (2016-10-04) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLIsWRmVeSWpSXmKPExsUixG6nojv/V1ikwatdLBZz3nxgsti++R+j A5PHjE/zWQIYo7hsUlJzMstSi/TtErgyNr3pYi2YIlyxZMVttgbGswJdjJwcEgImEiemv2Hv YuTiEBJYzCRx5NBdNghnI6PE9Nb1LBDOVSaJb3OWsYC0sAioSlxaN5EZxGYTUJNYv+IamC0i IC+xr+k9O4jNDGT/2toEZgsLmEss+/WdFcTmBVq3ZFobI4QtKHFy5hMWiPoyiaYDj5m6GDmA bGmJ5f84QMKiAsoSfw/fY5nAyDcLSccsJB2zEDogwloSN/69xBS2lVi37j3LAka2VYyyKblV urmJmTnFqcm6xcmJeXmpRbpGermZJXqpKaWbGEEhyynJu4Px312vQ4wCHIxKPLwbQsIihVgT y4orcw8xSnIwKYnyrrwWGinEl5SfUpmRWJwRX1Sak1p8iFEFaNejDasvMEqx5OXnpSqJ8D57 C9TKm5JYWZValA9TJs3BoiTOK67RGCEkkJ5YkpqdmlqQWgSTleHgUJLgdf4J1ChYlJqeWpGW mVOCkGbi4DzEKMHBAzR8yhmQ4cUFibnFmekQ+VOMilLivPEgzQIgiYzSPLheUKqRyN5f84pR HOgtYV6TH0BVPMA0Bdf9CmgwE9Bg4RkhIINLEhFSUg2M+mdS82sWiG+cXXXapKou0n2LcrrJ i7evl+fekbc35sr6Ws0QUrzsneFro2brH4Ktm47cEtzntPHdF44UGS2vdfrtEW8Uwy0/iXVM yX8zS7ziBuPO8FnO80USo7iurtn46ZCOoKRg9p9JRVcXXXr18eaUTfLpoQn/TzwNW72Hozog 49jbVQ29SizFGYmGWsxFxYkATUlMghADAAA= 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, 01 Jul 2017 01:33:09 -0000 --qlTNgmc+xy1dBmNv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear FreeBSD Community, Only one week remains before the July 7 deadline for submitting entries for the next FreeBSD Quarterly Status update, covering work done in April through June. Please consider submitting an entry for work you have done this quarter, even if it seems minor to you. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and provide a great way to inform FreeBSD users and developers about work that is underway and completed. Submission of reports is not restricted to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred and easiest submission method is to use the XML generator [1] with the results emailed to the status report team at monthly@FreeBSD.org . (Do be sure, though, to save the form output and not the form itself!) There is also an XML template [2] that can be filled out manually and attached if preferred. For the expected content and style, please study our guidelines on how to write a good status report [3]. You can also review previous issues [4][5] for ideas on the style and format. We look forward to seeing your 2017 reports! Thanks, Ben (on behalf of monthly@) [1] https://www.FreeBSD.org/cgi/monthly.cgi [2] https://www.FreeBSD.org/news/status/report-sample.xml [3] https://www.FreeBSD.org/news/status/howto.html [4] https://www.FreeBSD.org/news/status/report-2017-01-2017-03.html [5] https://www.FreeBSD.org/news/status/report-2016-10-2016-12.html --qlTNgmc+xy1dBmNv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGgBAABCgAGBQJZVvqSAAoJECjZpvNk63USigIMH2uZpCt+ofKjIx8T5oWRWVrd y8C2iNPcaFO6dvWPTV+UjMjvAlAMSV3wvLhxTW98Mw1uUkm1e1XnQ3JebXVEMPNi +PyNao3UTCKr63T6YKKCH7vqmFZRLebjCqTIhexlHxJl7S7ZcWfbddFuSMN62ASb 6enV8w+B3UY9KagbAh5S2LYk3gYuqhXMaqaecnCGbBn5O54WYzwRbRK13ekXsWXm k6jtF6GE7Pcoe1LsOIhrBawpgMCVxRaOvdjW2WhC/Ozd10Tg9wX6yQ6PEw1IgD6W Npmi3EYO3XIS4gp1z1LLkjE6i0V4elJ1a3AbIfCUQU2/6AsnOpvxF9zET874fMIq U/dGy7642IeSuAwQrWBk3/HdNnB1Dc5x2u2lq3pOAs6iI8pBpzTVL4CZETITNpoO h+24u51/4BKm+nZJHJvCm383eH1LfZFfT7/kzcjoUhb63bCimuknvFDQyeriEao1 7vK262ZC0OGV5LH658vxeR4vTMjZimWoMWxBsvwGE1hxZGw= =3b6G -----END PGP SIGNATURE----- --qlTNgmc+xy1dBmNv-- From owner-freebsd-hackers@freebsd.org Sat Jul 1 01:50: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 48D00DA11DD for ; Sat, 1 Jul 2017 01:50:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (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 093921A9F for ; Sat, 1 Jul 2017 01:50:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25832 invoked from network); 1 Jul 2017 01:50:42 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 1 Jul 2017 01:50:42 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Fri, 30 Jun 2017 21:50:42 -0400 (EDT) Received: (qmail 18686 invoked from network); 1 Jul 2017 01:50:42 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 1 Jul 2017 01:50:42 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 47185EC81E6; Fri, 30 Jun 2017 18:50:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r320482 vs. TARGET_ARCH=powerpc production style kernel: jumps to non-code and traps (involves ->sol_upcall pointing to ->so_rdsel) bugzilla 220404 From: Mark Millard In-Reply-To: <1F24D891-4D11-4623-8183-7F95D9637FB2@dsl-only.net> Date: Fri, 30 Jun 2017 18:50:40 -0700 Cc: Justin Hibbits , Nathan Whitehorn Content-Transfer-Encoding: quoted-printable Message-Id: <3C743FFC-2E40-4077-988C-8C4BFBA7556B@dsl-only.net> References: <1F24D891-4D11-4623-8183-7F95D9637FB2@dsl-only.net> To: glebius@FreeBSD.org, FreeBSD PowerPC ML , FreeBSD Current , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) 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, 01 Jul 2017 01:50:44 -0000 [It looks like the 2 anonymous structs in the union in the new "struct socket" are being abused such that the ->sol_upcall from the 2nd struct is being access when it has a value that was apparently assigned via ->so_rcv->sb_sel . Details follow, added to prior notes that I sent out. I've submitted bugzilla 220404 for this. The new detailed material is interlaced with earlier material that I'd sent out.] On 2017-Jun-30, at 2:07 AM, Mark Millard wrote: > The -r320482 kernel build is via gcc 4.2.1. > Both gcc 4.2.1 and clang based worlds show > the same problems. TARGET_ARCH=3Dpowerpc64 > is not showing the problems. >=20 > The production kernel build fails > but the debug works --each built > from the same /usr/src/ tree. >=20 > I'll note what a normal boot does > before getting to the login prompt but > after "Starting nfsd." ("Updating motd:" > can be mixed in the trap text: not shown > below.) >=20 > I use an example and note a lot about what > varies and what stays the same from example > boot to example boot of the production > kernel. >=20 > [Manually entered from camera pictures > of the screen.] >=20 > fatal kernel trap > exception =3D 0x700 (program) (for "illegal instruction") > srr0 =3D 0x70bf878 (note: this varies, for example: 0x5e37230) > (note: r0 always matches srr0) > (note: ctr always matches srr0) > srr1 =3D 0x89032 (stays the same) > lr =3D 0x5b7b94 (note: solisten_wakeup+0x4c) (stays the same) > curthread =3D 0x5ab8ae0 (varies) > pid =3D 920 (varies), comm =3D mountd (stays the same) >=20 > Tracing command mountd pid 920 tid 100119 (varies) td 0x5ab8ae0 = (varies)(CPU 1) > (stack addr > range varies) > 0xd250a500: at soisconnected+0x21c (at stays the same) > 0xd250a540: at unp_connect2+0xf0 (at stays the same) > 0xd250a560: at unp_connectat+0x658 (at stays the same) > 0xd250a770: at unp_connect+0x2c (at stays the same) > 0xd250a790: at uipc_connect+0xc0 (at stays the same) > 0xd250a7d0: at soconnectat+0xa0 (at stays the same) > 0xd250a800: at soconnect+0x2c (at stays the same) > 0xd250a820: at kern_connect+0134 (at stays the same) > 0xd250a870: at sys_connect+0x64 (at stays the same) > 0xd250a8b0: at trap+0x638 (at stays the same) > 0xd250aa50: at powerpc_interrupt+0x1a0 (at stays the same) > 0xd250aa80: at user SC trap (at stays the same) > by 0x419db168 (stays the same) > srr1=3D0xf032 (stays the same) > r1 =3D0xffffd5e0 (stays the same) > cr =3D0x24440840 (stays the same) > xer =3D0x20000000 (stays the same) > ctr =3D0x419db160 (stays the same) (these are objdump reported addresses) > 005b7b48 stwu r1,-32(r1) > 005b7b4c mflr r0 > 005b7b50 stw r29,20(r1) > 005b7b54 stw r30,24(r1) > 005b7b58 stw r31,28(r1) > 005b7b5c stw r0,36(r1) > 005b7b60 mr r31,r1 > 005b7b64 bcl- 20,4*cr7+so,005b7b68 = > 005b7b68 mflr r30 > 005b7b6c lwz r0,-36(r30) > 005b7b70 add r30,r0,r30 > 005b7b74 mr r29,r3 > 005b7b78 lwz r0,232(r3) > 005b7b7c cmpwi cr7,r0,0 > 005b7b80 beq- cr7,005b7b98 = > 005b7b84 lwz r4,236(r3) > 005b7b88 li r5,1 > 005b7b8c mtctr r0 > 005b7b90 bctrl > lr: > 005b7b94 b 005b7bb4 = > . . . >=20 > Apparently this means that sol->sol_upcall is not > pointing to code at all yet is not null. Given the > variability observed, it might be uninitialized > --or sol itself is junk. . . Note: r3 reported as: 0x70bf860 void solisten_wakeup(struct socket *sol) { if (sol->sol_upcall !=3D NULL) (void )sol->sol_upcall(sol, sol->sol_upcallarg, = M_NOWAIT); else { selwakeuppri(&sol->so_rdsel, PSOCK); KNOTE_LOCKED(&sol->so_rdsel.si_note, 0); } SOLISTEN_UNLOCK(sol); wakeup_one(&sol->sol_comp); } (kgdb) print/x &((struct socket*)0x70bf860)->sol_upcall $3 =3D 0x70bf948 (kgdb) print/x ((struct socket*)0x70bf860)->sol_upcall $2 =3D 0x70bf878 (kgdb) print/x &((struct socket*)0x70bf860)->so_rdsel $7 =3D 0x70bf878 (kgdb) print/x &((struct socket*)0x70bf860)->so_rdsel.si_tdlist $8 =3D 0x70bf878 (kgdb) print/x &((struct = socket*)0x70bf860)->so_rdsel.si_tdlist.tqh_first $9 =3D 0x70bf878 But comparing to the first anonymous struct in the union in the new "struct socket": (kgdb) print/x &((struct socket*)0x70bf860)->sol_upcall $15 =3D 0x70bf948 (kgdb) print/x &((struct socket*)0x70bf860)->so_rcv->sb_sel $22 =3D 0x70bf948 ->so_rcv is a struct sockbuf and ->so_rcv->sb_sel is a struct slinfo* . So pointing back to ->so_rdsel might well make sense. The rest is just supporting notes from things that I looked at before isolating the above relationship. (these are kgdb reported addresses, not vmcore.5 file offsets) 0x70bf860: 0x00c4a0b4 0x01430000 0x00000000 = 0x00000000 . . . 0x70bf940: 0x00000000 0x00000000 0x070bf878 = 0x00000000 but: 0x70bf870: 0x05ab8ae0 0x00000002 0x07271f80 = 0x07271f84 (kgdb) print/x *((struct socket*)0x70bf860) =20 $4 =3D {so_lock =3D {lock_object =3D {lo_name =3D 0xc4a0b4, lo_flags =3D = 0x1430000, lo_data =3D 0x0, lo_witness =3D 0x0}, mtx_lock =3D = 0x5ab8ae0}, so_count =3D 0x2, so_rdsel =3D {si_tdlist =3D {tqh_first =3D = 0x7271f80,=20 tqh_last =3D 0x7271f84}, si_note =3D {kl_list =3D {slh_first =3D = 0x0}, kl_lock =3D 0x5b6e84, kl_unlock =3D 0x5b6c64, kl_assert_locked =3D = 0x5b65d4, kl_assert_unlocked =3D 0x5b65f0, kl_lockarg =3D 0x70bf860,=20 kl_autodestroy =3D 0x0}, si_mtx =3D 0x5ab01f0}, so_wrsel =3D = {si_tdlist =3D {tqh_first =3D 0x0, tqh_last =3D 0x0}, si_note =3D = {kl_list =3D {slh_first =3D 0x0}, kl_lock =3D 0x5b6d64, kl_unlock =3D = 0x5b6b64,=20 kl_assert_locked =3D 0x5b660c, kl_assert_unlocked =3D 0x5b6628, = kl_lockarg =3D 0x70bf860, kl_autodestroy =3D 0x0}, si_mtx =3D 0x0}, = so_type =3D 0x1, so_options =3D 0x2, so_linger =3D 0x0, so_state =3D = 0x0,=20 so_pcb =3D 0x70b08a0, so_vnet =3D 0x0, so_proto =3D 0xd03060, so_timeo = =3D 0x0, so_error =3D 0x0, so_sigio =3D 0x0, so_cred =3D 0x5b2e600, = so_label =3D 0x0, so_gencnt =3D 0x1285, so_emuldata =3D 0x0, osd =3D { osd_nslots =3D 0x0, osd_slots =3D 0x0, osd_next =3D {le_next =3D = 0x0, le_prev =3D 0x0}}, so_fibnum =3D 0x0, so_user_cookie =3D 0x0, = so_ts_clock =3D 0x0, so_max_pacing_rate =3D 0x0, {{so_rcv =3D {sb_mtx =3D = { lock_object =3D {lo_name =3D 0x0, lo_flags =3D 0x70bf920, = lo_data =3D 0x5d17860, lo_witness =3D 0x5d17a60}, mtx_lock =3D 0x1}, = sb_sx =3D {lock_object =3D {lo_name =3D 0x0, lo_flags =3D 0x80, lo_data = =3D 0x0,=20 lo_witness =3D 0x0}, sx_lock =3D 0x0}, sb_sel =3D 0x70bf878, = sb_state =3D 0x0, sb_mb =3D 0x1, sb_mbtail =3D 0x800, sb_lastrecord =3D = 0x2000, sb_sndptr =3D 0x2000, sb_fnrdy =3D 0x0, sb_sndptroff =3D 0x0,=20 sb_acc =3D 0x0, sb_ccc =3D 0x0, sb_hiwat =3D 0x0, sb_mbcnt =3D = 0x0, sb_mcnt =3D 0x0, sb_ccnt =3D 0x0, sb_mbmax =3D 0x0, sb_ctl =3D 0x0, = sb_lowat =3D 0x1, sb_timeo =3D 0x0, sb_flags =3D 0x0, sb_upcall =3D 0x0,=20= sb_upcallarg =3D 0x0, sb_aiojobq =3D {tqh_first =3D 0x0, = tqh_last =3D 0x70bf9a4}, sb_aiotask =3D {ta_link =3D {stqe_next =3D = 0x0}, ta_pending =3D 0x0, ta_priority =3D 0x0, ta_func =3D 0x58eeb4,=20 ta_context =3D 0x70bf860}}, so_snd =3D {sb_mtx =3D = {lock_object =3D {lo_name =3D 0xc588cc, lo_flags =3D 0x1020000, lo_data = =3D 0x0, lo_witness =3D 0x0}, mtx_lock =3D 0x6}, sb_sx =3D {lock_object = =3D { lo_name =3D 0xc58efc, lo_flags =3D 0x2320000, lo_data =3D = 0x0, lo_witness =3D 0x0}, sx_lock =3D 0x6}, sb_sel =3D 0x70bf8a0, = sb_state =3D 0x0, sb_mb =3D 0x0, sb_mbtail =3D 0x0, sb_lastrecord =3D = 0x0,=20 sb_sndptr =3D 0x0, sb_fnrdy =3D 0x0, sb_sndptroff =3D 0x0, = sb_acc =3D 0x0, sb_ccc =3D 0x0, sb_hiwat =3D 0x0, sb_mbcnt =3D 0x0, = sb_mcnt =3D 0x0, sb_ccnt =3D 0x0, sb_mbmax =3D 0x0, sb_ctl =3D 0x0, = sb_lowat =3D 0x800,=20 sb_timeo =3D 0x0, sb_flags =3D 0x0, sb_upcall =3D 0x0, = sb_upcallarg =3D 0x0, sb_aiojobq =3D {tqh_first =3D 0x0, tqh_last =3D = 0x70bfa44}, sb_aiotask =3D {ta_link =3D {stqe_next =3D 0x0}, ta_pending = =3D 0x0,=20 ta_priority =3D 0x0, ta_func =3D 0x58ee80, ta_context =3D = 0x70bf860}}, so_list =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0}, so_listen = =3D 0x0, so_qstate =3D 0x0, so_peerlabel =3D 0x0, so_oobmark =3D 0x0}, { sol_incomp =3D {tqh_first =3D 0x0, tqh_last =3D 0x70bf920}, = sol_comp =3D {tqh_first =3D 0x5d17860, tqh_last =3D 0x5d17a60}, sol_qlen = =3D 0x1, sol_incqlen =3D 0x0, sol_qlimit =3D 0x80, sol_accept_filter =3D = 0x0,=20 sol_accept_filter_arg =3D 0x0, sol_accept_filter_str =3D 0x0, = sol_upcall =3D 0x70bf878, sol_upcallarg =3D 0x0, sol_sbrcv_lowat =3D = 0x1, sol_sbsnd_lowat =3D 0x800, sol_sbrcv_hiwat =3D 0x2000,=20 sol_sbsnd_hiwat =3D 0x2000, sol_sbrcv_flags =3D 0x0, = sol_sbsnd_flags =3D 0x0, sol_sbrcv_timeo =3D 0x0, sol_sbsnd_timeo =3D = 0x0}}} For lo_name in sb_sx's lock_object: (kgdb) x/64c 0xc58ef0 0xc58ef0 <.rodata.str1.4+376864>: 116 't' 109 'm' 99 'c' 111 'o' = 112 'p' 121 'y' 105 'i' 110 'n' 0xc58ef8 <.rodata.str1.4+376872>: 0 '\0' 0 '\0' 0 '\0' 0 '\0' = 115 's' 111 'o' 95 '_' 115 's' 0xc58f00 <.rodata.str1.4+376880>: 110 'n' 100 'd' 95 '_' 115 's' = 120 'x' 0 '\0' 0 '\0' 0 '\0' which looks coherent to me: so_snd_sx For ta_func in sb_aiotask: (kgdb) x/64i 0x58ee80 0x58ee80 : stwu r1,-32(r1) . . . Looks coherent to me. But sol_upcall does not. >=20 >=20 > 005b8548 li r10,1 > 005b854c b 005b8558 > 005b8550 stwcx. r10,0,r9 > 005b8554 li r10,0 > 005b8558 cmpwi cr7,r10,0 > 005b855c bne- cr7,005b8568 = > 005b8560 addi r3,r28,16 > 005b8564 bl 004d4218 <__mtx_unlock_sleep> > 005b8568 mr r3,r27 > at soisconnected+0x21c: > 005b856c bl 005b7b48 > 005b8570 b 005b89f0 > . . . >=20 > void > soisconnected(struct socket *so) > { > struct socket *head; > . . . > restart: =20 > SOCK_LOCK(so); > if ((head =3D so->so_listen) !=3D NULL && > __predict_false(SOLISTEN_TRYLOCK(head) =3D=3D 0)) { > SOCK_UNLOCK(so); > goto restart; > } =20 > so->so_state &=3D = ~(SS_ISCONNECTING|SS_ISDISCONNECTING|SS_ISCONFIRMING); > so->so_state |=3D SS_ISCONNECTED; > if (head !=3D NULL && (so->so_qstate =3D=3D SQ_INCOMP)) { > again: > if ((so->so_options & SO_ACCEPTFILTER) =3D=3D 0) { > TAILQ_REMOVE(&head->sol_incomp, so, so_list); > head->sol_incqlen--; > TAILQ_INSERT_TAIL(&head->sol_comp, so, = so_list); > head->sol_qlen++; > so->so_qstate =3D SQ_COMP; > SOCK_UNLOCK(so); > solisten_wakeup(head); /* unlocks */ > . . . Exception and its struct trapframe: (these are vmcore file offsets: subtract 0x1000 to get address) [ lr#0 ]: inside dbtrap 00c83f40 d2 50 a4 e0 00 10 0c 54 07 0b f8 78 d2 50 a4 e0 = |.P.....T...x.P..| 00c83f50 05 ab 8a e0 07 0b f8 60 00 00 00 00 00 00 00 01 = |.......`........| [ r3 ] 00c83f60 00 00 00 00 00 00 00 01 00 00 00 00 05 d1 78 70 = |..............xp| 00c83f70 00 00 00 01 05 ab 8a e0 00 00 00 00 00 00 00 00 = |................| 00c83f80 01 81 00 00 01 82 00 00 00 00 00 00 01 82 00 00 = |................| 00c83f90 01 82 00 00 00 03 8d 6c 00 03 8d 6c 00 00 00 00 = |.......l...l....| 00c83fa0 ff ff d7 58 00 00 00 00 00 d1 1a 84 00 d1 1a 84 = |...X............| 00c83fb0 d2 50 a5 1c 07 0b f8 60 05 d1 78 60 07 0b f8 60 = |.P.....`..x`...`| [ r28 ] 00c83fc0 00 d2 aa a0 d2 50 a4 e0 00 5b 7b 94 20 00 f0 44 = |.....P...[{. ..D| [ lr#1 ]: solisten_wakeup+0x4c 00c83fd0 00 00 00 00 07 0b f8 78 07 0b f8 78 00 08 90 32 = |.......x...x...2| [ srr0 ] [exception] 00c83fe0 00 00 07 00 00 00 00 00 00 00 00 00 01 c4 5f 00 = |.............._.| 00c83ff0 00 00 00 00 00 10 01 40 00 00 00 00 00 00 00 00 = |.......@........| solisten_wakeup+0x4c's related stack frame: 0b4004e0 d2 50 a5 00 00 50 8d f8 00 d2 b0 60 00 00 00 04 = |.P...P.....`....| 0b4004f0 05 d1 7a 78 05 d1 79 30 00 d2 aa a0 d2 50 a5 00 = |..zx..y0.....P..| 0xd250a500: at soisconnected+0x21c (at stays the same) 0b400500 d2 50 a5 40 00 5b 85 70 00 d2 aa a0 d2 50 a5 10 = |.P.@.[.p.....P..| 0b400510 d2 50 a5 60 00 5b d0 d8 00 d2 ab 90 00 00 00 04 = |.P.`.[..........| 0b400520 05 d1 78 60 05 ab 8a e0 07 25 94 80 05 d1 7a 78 = |..x`.....%....zx| 0b400530 07 0b 7a 10 05 d1 78 60 00 d2 ab 90 d2 50 a5 40 = |..z...x`.....P.@| 0xd250a540: at unp_connect2+0xf0 (at stays the same) 0b400540 d2 50 a5 60 00 5c 38 34 07 25 94 80 05 d1 7a 78 = |.P.`.\84.%....zx| 0b400550 07 0b 7a 10 07 0b 79 58 00 d2 ab 90 d2 50 a5 60 = |..z...yX.....P.`| "so" first then "so2" second, with so2 failing: 0x005c3824 : mr r3,r8 0x005c3828 : bl 0x5b8350 0x005c382c : mr r3,r29 0x005c3830 : bl 0x5b8350 0x005c3834 : li r3,0 static int unp_connect2(struct socket *so, struct socket *so2, int req) . . . case SOCK_STREAM: case SOCK_SEQPACKET: unp2->unp_conn =3D unp; if (req =3D=3D PRU_CONNECT && ((unp->unp_flags | unp2->unp_flags) & UNP_CONNWAIT)) soisconnecting(so); else soisconnected(so); soisconnected(so2); break; . . . 0xd250a560: at unp_connectat+0x658 (at stays the same) 0b400560 d2 50 a7 70 00 5c 3e c4 05 ab 8a e0 00 fd c1 c0 = |.P.p.\>.........| 0b400570 d2 50 a6 3d 00 00 00 01 02 00 01 00 00 00 04 00 = |.P.=3D............| 0b400580 04 00 00 00 00 00 00 00 00 00 00 00 05 a3 7c 60 = |..............|`| 0b400590 00 00 00 00 ff ff ff 9c 00 00 00 00 00 fd c1 c0 = |................| 0b4005a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| 0b4005b0 00 00 00 00 ff ff 00 00 00 00 00 00 00 00 00 00 = |................| 0b4005c0 07 25 94 80 05 a3 72 40 00 00 00 01 05 b2 10 15 = |.%....r@........| 0b4005d0 00 00 00 00 00 8c 05 bc 00 00 00 00 44 eb 41 81 = |............D.A.| 0b4005e0 00 00 00 00 00 00 c1 44 05 ab 8a e0 05 b2 e6 00 = |.......D........| 0b4005f0 00 20 00 00 05 b2 10 00 05 b2 10 09 00 00 00 0c |. = ..............| 0b400600 00 00 00 00 d2 50 a6 00 00 d3 23 bc 00 ce eb 40 = |.....P....#....@| 0b400610 07 25 94 80 d2 50 a6 38 05 b2 e6 00 05 ab 8a e0 = |.%...P.8........| 0b400620 02 00 01 00 00 00 04 00 04 00 00 00 00 00 00 00 = |................| 0b400630 05 c9 91 ec 00 00 00 04 07 0b 79 58 d2 2f 76 61 = |..........yX./va| 0b400640 72 2f 72 75 6e 2f 72 70 63 62 69 6e 64 2e 73 6f = |r/run/rpcbind.so| 0b400650 63 6b 00 70 00 00 00 05 00 00 00 00 00 00 00 10 = |ck.p............| 0b400660 05 d8 c4 80 d0 21 56 d4 00 d3 23 bc 00 00 00 04 = |.....!V...#.....| 0b400670 d2 50 a6 a0 40 00 f0 34 00 d1 1a 84 00 f5 0d 00 = |.P..@..4........| 0b400680 00 f5 0d 00 00 d1 1a 84 05 c9 91 ec 00 00 00 08 = |................| 0b400690 41 99 00 00 05 c2 49 d8 41 98 80 00 41 98 c0 00 = |A.....I.A...A...| 0b4006a0 00 00 00 07 00 00 00 05 d0 21 57 c8 41 99 00 00 = |.........!W.A...| 0b4006b0 05 c9 91 ec 00 fd c1 c0 00 d3 36 8c d2 50 a6 c0 = |..........6..P..| 0b4006c0 d2 50 a6 e0 00 8c 74 c0 05 c9 91 38 00 00 00 04 = |.P....t....8....| 0b4006d0 d2 50 a6 f0 00 fd c1 c0 d2 50 a6 e0 d2 50 a6 e0 = |.P.......P...P..| 0b4006e0 d2 50 a7 10 00 8f a0 94 d2 50 a6 f0 d2 50 a6 f0 = |.P.......P...P..| 0b4006f0 d2 50 a7 10 00 00 00 00 00 00 01 21 00 00 00 41 = |.P.........!...A| 0b400700 00 00 00 06 05 be e4 c0 00 d2 ab 64 d2 50 a7 10 = |...........d.P..| 0b400710 d2 50 a7 80 00 48 f2 70 00 d3 11 94 d2 50 a7 20 = |.P...H.p.....P. | 0b400720 d2 50 a7 40 00 87 1c 04 02 00 07 ff ff ff ff ff = |.P.@............| 0b400730 04 00 00 00 00 1f ff ff 00 d3 10 54 68 a4 aa 22 = |...........Th.."| 0b400740 d2 50 a7 60 00 87 1c 40 00 00 00 00 05 ab 8a e0 = |.P.`...@........| 0b400750 05 ab 8a e0 ff ff ff 9c 05 ab 8a e0 05 ab 8a e0 = |................| 0b400760 05 b1 54 20 05 d1 7a 78 00 d2 ab 90 d2 50 a7 70 |..T = ..zx.....P.p| The unp_connectat context is more complicated so I stop quoting code here. 0xd250a770: at unp_connect+0x2c (at stays the same) 0b400770 d2 50 a7 90 00 5c 41 c8 00 d2 ab 64 d2 50 a7 80 = |.P...\A....d.P..| 0b400780 d2 50 a7 e0 00 48 f5 e0 d2 50 a7 90 00 00 00 00 = |.P...H...P......| 0xd250a790: at uipc_connect+0xc0 (at stays the same) 0b400790 d2 50 a7 d0 00 5c 7b cc 00 00 00 06 05 be e4 c0 = |.P...\{.........| 0b4007a0 d2 50 a8 10 00 86 32 e8 20 00 f0 38 00 00 00 01 |.P....2. = ..8....| 0b4007b0 00 03 8d 6c 00 00 00 00 ff ff d7 58 05 b1 54 20 = |...l.......X..T | 0b4007c0 ff ff ff 9c 05 d1 7a 78 00 d2 ab 64 d2 50 a7 d0 = |......zx...d.P..| 0xd250a7d0: at soconnectat+0xa0 (at stays the same) 0b4007d0 d2 50 a8 00 00 5b 61 68 00 d2 ab 64 d2 50 a7 e0 = |.P...[ah...d.P..| 0b4007e0 d2 50 a8 20 00 5b ff 64 05 b1 54 20 05 ab 8a e0 |.P. .[.d..T = ....| 0b4007f0 00 00 00 00 05 d1 7a 78 00 d2 ab 64 d2 50 a8 00 = |......zx...d.P..| 0xd250a800: at soconnect+0x2c (at stays the same) 0b400800 d2 50 a8 20 00 5b 61 f4 05 b1 54 20 05 ab 8a e0 |.P. .[a...T = ....| 0b400810 00 00 00 25 05 d1 7a 78 d2 50 a8 20 d2 50 a8 20 |...%..zx.P. = .P. | 0xd250a820: at kern_connect+0134 (at stays the same) 0b400820 d2 50 a8 70 00 5c 19 14 ff ff d7 68 00 00 00 16 = |.P.p.\.....h....| 0b400830 00 00 00 17 05 b1 54 20 02 00 00 00 80 00 00 00 |......T = ........| 0b400840 04 00 00 00 00 00 00 00 41 98 c0 00 05 be e4 c0 = |........A.......| 0b400850 05 ab 8a e0 00 00 00 00 d2 50 aa 88 05 ab 8a e0 = |.........P......| 0b400860 00 00 00 00 05 ab 8d 78 00 d2 ab 64 d2 50 a8 70 = |.......x...d.P.p| 0xd250a870: at sys_connect+0x64 (at stays the same) 0b400870 d2 50 a8 b0 00 5c 1c 58 d2 50 aa 88 00 00 04 00 = |.P...\.X.P......| 0b400880 00 00 00 01 d2 50 aa 88 00 00 00 80 05 b1 54 20 = |.....P........T | 0b400890 d2 50 a8 b0 00 8f c3 b0 d2 50 aa 88 00 00 00 00 = |.P.......P......| 0b4008a0 05 ab 8d 70 05 d9 5a b0 00 d3 37 e8 d2 50 a8 b0 = |...p..Z...7..P..| 0xd250a8b0: at trap+0x638 (at stays the same) 0b4008b0 d2 50 aa 50 00 8f cc 3c 5a 2e a6 14 b1 ae c2 60 = |.P.P... 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 82B85D8B0C3 for ; Sat, 1 Jul 2017 05:16:15 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 6887F7873D for ; Sat, 1 Jul 2017 05:16:15 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: by mailman.ysv.freebsd.org (Postfix) id 67A61D8B0C0; Sat, 1 Jul 2017 05:16:15 +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 672E2D8B0BF for ; Sat, 1 Jul 2017 05:16:15 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (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 271F97873C for ; Sat, 1 Jul 2017 05:16:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15928 invoked from network); 1 Jul 2017 05:20:28 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 1 Jul 2017 05:20:28 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Sat, 01 Jul 2017 01:16:13 -0400 (EDT) Received: (qmail 29572 invoked from network); 1 Jul 2017 05:16:13 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 1 Jul 2017 05:16:13 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 94B7BEC81E6; Fri, 30 Jun 2017 22:16:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: extract panic message & debugging from vmcore.0 ? From: Mark Millard In-Reply-To: Date: Fri, 30 Jun 2017 22:16:11 -0700 Cc: hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170630021205.GA43579@mail.michaelwlucas.com> To: "Michael W. Lucas" X-Mailer: Apple Mail (2.3273) 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, 01 Jul 2017 05:16:15 -0000 [Some more notes prompted by your reply.] On 2017-Jun-29, at 7:35 PM, Mark Millard wrote: > On 2017-Jun-29, at 7:12 PM, Michael W. Lucas wrote: >=20 >>=20 >> # cd /usr/obj/usr/src/sys/GENERIC >> # make gdbinit >> # gdb kernel.debug >=20 > Did you miss a /var/crash/vmcore.0 above? I should have noted that gdbinit is likely for setting up to use gdb remotely against a live system for remote kernel debugging. (Not something that I've ever done.) It likely does nothing useful for vmcore.* inspection. gdb itself does not deal with vmcore.* files to my knowledge. So this likely was instead a false direction for your purposes. > Separately. . . >=20 > I'm no expert but you might need to pick > between the default minidump vs. a full > memory dump depending on purposes and what > information is to be extracted: >=20 > debug.minidump: 1 > vs. > debug.minidump: 0 >=20 > in the sysctl debug.minidump output. I > doubt that they are fully equivalent. >=20 > Of course a full memory dump implies > needing space ready to hold that full > copy. I'll also note that virtual addresses vs. physical addresses are likely an issue for at least debug.minidump=3D0 . As for the crashinfo that you mention in your reply: On head -320482 . . . # grep -r crashinfo /etc /etc/rc.d/savecore: if checkyesno crashinfo_enable; then /etc/rc.d/savecore: ${crashinfo_program} -b -d = ${dumpdir} /etc/defaults/rc.conf:crashinfo_enable=3D"YES" # Automatically generate = crash dump summary. /etc/defaults/rc.conf:crashinfo_program=3D"/usr/sbin/crashinfo" # Script = to generate crash dump summary. Normally the boot sequence produces a crashinfo report after creating the vmcore.* file, at least if crashinfo is enabled. The context for the below is a powerpc with debug.minidump=3D0 (disabled) and a production kernel for the failures. (The debug kernel does not get the problems involved for head -r320482 .) vmcore.*'s, core.txt.*'s, info.*'s and *.last's were all produced towards the end of the boot sequence before the login prompt each time. # ls -lT /var/crash/ total 2685292 -rw-r--r-- 1 root wheel 2 Jun 29 23:17:52 2017 bounds -rw------- 1 root wheel 0 Jun 29 22:47:14 2017 core.txt.5 -rw------- 1 root wheel 26573 Jun 29 23:18:51 2017 core.txt.6 -rw------- 1 root wheel 351 Jun 29 22:46:15 2017 info.5 -rw------- 1 root wheel 378 Jun 29 23:17:52 2017 info.6 lrwxr-xr-x 1 root wheel 0 Jun 29 22:47:06 2017 info.last ->=20= -rw-r--r-- 1 root wheel 5 Feb 22 02:37:33 2016 minfree -rw------- 1 root wheel 2147487744 Jun 29 22:47:06 2017 vmcore.5 -rw------- 1 root wheel 2147487744 Jun 29 23:18:43 2017 vmcore.6 lrwxr-xr-x 1 root wheel 0 Jun 29 22:47:06 2017 vmcore.last = ->=20 (There are oddities for the system that have made the links and core.txt.5 empty.) # more /var/crash/info.5 Dump header from device: /dev/label/FBSDG4Sswap Architecture: powerpc Architecture Version: 1 Dump Length: 2147487744 Blocksize: 512 Dumptime: Thu Jun 29 22:34:22 2017 Hostname: FBSDG4S Magic: FreeBSD Kernel Dump Version String: FreeBSD 12.0-CURRENT r320482M Panic String:=20 Dump Parity: 4013015019 Bounds: 5 Dump Status: good core.txt.6 attempted to have sections for: ps -axlww vmstat -s vmstat -m vmstat -z vmstat -i pstat -T pstat -s iostat ipcs -a ipcs -T nfsstat netstat -s netstat -m netstat -anA netstat -aL fstat dmesg kernel config ddb capture buffer (That does not mean that they all were useful/accurate.) I'll not list the text here. Notes: powerpc is not actually supported for kgdb and the like and I had to change some things to get this much working as well as it does for me now. (It is limited but has been useful to me.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Sat Jul 1 08:25: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 C6EA6DA15DA for ; Sat, 1 Jul 2017 08:25:30 +0000 (UTC) (envelope-from ap00@mail.ru) Received: from smtp36.i.mail.ru (smtp36.i.mail.ru [94.100.177.96]) (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 78CC27DF39 for ; Sat, 1 Jul 2017 08:25:29 +0000 (UTC) (envelope-from ap00@mail.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Subject:CC:To:Message-ID:From:Date; bh=Q4gkZlNol/H3IGiOP8Cqdyhe7ojP4EnYqgASwTo/OPc=; b=pqQSUQVzUoZY5/ueeFZ8FJfBQdFIPFFui8z0m0U3FXhoGVVJx9hp7hBgeHbKd1czF9umn2UgO8BWOGJHYQ96tw4ckD+u5vnW01c3PxiFpvpm5mU/4aBqLSDGoeZ9jjrHy5OA5i5Thh7Atsx9MDu4OujxaZtoXkN8LEnmRHyJZ5c=; Received: from [91.190.121.202] (port=49232 helo=[192.168.192.10]) by smtp36.i.mail.ru with esmtpa (envelope-from ) id 1dRDiS-0008HP-96; Sat, 01 Jul 2017 11:25:20 +0300 Date: Sat, 1 Jul 2017 11:25:18 +0300 From: Anthony Pankov X-Priority: 3 (Normal) Message-ID: <1656711497.20170701112518@mail.ru> To: Jilles Tjoelker CC: freebsd-hackers@freebsd.org Subject: Re: using rc.subr only by root restriction In-Reply-To: <20170630222709.GA74602@stack.nl> References: <1599987034.20170623182536@mail.ru> <20170630222709.GA74602@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Authentication-Results: smtp36.i.mail.ru; auth=pass smtp.auth=ap00@mail.ru smtp.mailfrom=ap00@mail.ru X-7FA49CB5: 0D63561A33F958A5EA86AA3B663DD6A6FEF2848491B8A80A1F42DF47398C4A6D725E5C173C3A84C3727597FF642BA4D74A448D8C3B069C2142F54486E6D6388DC4224003CC836476C0CAF46E325F83A50BF2EBBBDD9D6B0F8DB212830C5B42F72623479134186CDE6BA297DBC24807EABDAD6C7F3747799A X-Mailru-Sender: D8D48EF70163D79D00784CDFC8FD3107ABAF719BFB34B4C65738E85548DE9FAAAA9FACF08E54A1E250D5CF8590B94F4EC77752E0C033A69E81198BD1A48777B793AC9912533B2342AE208404248635DF X-Mras: OK 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, 01 Jul 2017 08:25:30 -0000 > I don't like that this starts id -u many times during startup. I also think that proposed patch is far away from beautiful solution. My second suggestion was to not apply login class until it explicity specified but this is also not a clear way. > Perhaps > you can use the id invocation in the code block that unsets $_user if > running as that user. Sorry, I didn't catch. > By the way, that code block seems to indicate that it was definitely > supposed to work to use rc.subr without root privileges. The concern > about resource limits and other context not matching normal boot is > valid, though. -- Best regards, Anthony mailto:ap00@mail.ru From owner-freebsd-hackers@freebsd.org Sat Jul 1 18:04:35 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 6580CD8F627 for ; Sat, 1 Jul 2017 18:04:35 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5679B6A2B6 for ; Sat, 1 Jul 2017 18:04:35 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yv.noip.me (c-24-6-186-56.hsd1.ca.comcast.net [24.6.186.56]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id v61I4SsN043763 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sat, 1 Jul 2017 11:04:29 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-24-6-186-56.hsd1.ca.comcast.net [24.6.186.56] claimed to be yv.noip.me To: Freebsd hackers list From: Yuri Subject: CUDA and FreeBSD: can linux kernel module be ported to FreeBSD? Message-ID: Date: Sat, 1 Jul 2017 11:04:27 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 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: Sat, 01 Jul 2017 18:04:35 -0000 NVidia CUDA toolkit (https://developer.nvidia.com/cuda-downloads) contains a lot of rpms. The kernel module rpm nvidia-kmod-375.26-2.el7.x86_64.rpm actually contains linux kernel module sources. The rest of rpms contain binary userland utilities. So if somebody could port those kernel sources into the FreeBSD kernel module, CUDA could be used over the linux emulation level? Is this true, or there are some other hurdles? (I didn't expect to find kernel module sources when I looked, hence this question.) Yuri