From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 27 23:26:32 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BF56576F for ; Sun, 27 Oct 2013 23:26:32 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5BE4A240E for ; Sun, 27 Oct 2013 23:26:32 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id hn9so3207515wib.11 for ; Sun, 27 Oct 2013 16:26:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=x7EbJAaACR0WWB45ylRzdWB4j1s452FPcvxWbFhIyfs=; b=hbxpPABI6ZJnHpvGt77N+ToB1CTQDiBM2hGI6QXL6MYwVyO/4u9rgLPAezIBaBRmYA JEGDpueVU671+zw5bjGVUIhpJiSMTfGbZ2hL0rw27WVTztvdHWzo0YOzC4dNE88mQRGN 0e+dwqAyDS0DiwbaKagiPUHTeomsZeAdbZ9zIwj3xtAyK+M6tpe0vecG3VEZU0ojDVvc sYStouapPzqm3OBUR8gVGsR5KGMj5SPdmn4JQo0dJ5sLookldM01pYMEV6rURkl9OpBr jhX+sK4uj0bvFdy3247GQQLQdAitN+oT90UMhGtc/dZcnHbIT/fkAjCkv0Ur8f29Ix/u 9LVQ== X-Received: by 10.194.109.68 with SMTP id hq4mr15979381wjb.12.1382916390782; Sun, 27 Oct 2013 16:26:30 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id pi6sm30090051wic.3.2013.10.27.16.26.29 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 27 Oct 2013 16:26:30 -0700 (PDT) Sender: Baptiste Daroussin Date: Mon, 28 Oct 2013 00:26:28 +0100 From: Baptiste Daroussin To: hackers@FreeBSD.org Subject: Importing netbsd cdb Message-ID: <20131027232628.GB74512@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EuxKj2iCbKjpUGkD" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 23:26:32 -0000 --EuxKj2iCbKjpUGkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all Here is a code that imports the cdbrw from netbsd into a new lib/libcdbrw library, the read part is also added to libc but not exposed. As an example of using that library I also got the service_mkdb patches from netbsd that makes it by default emit a cdb database and add a switch to all= ow it to still create the old .db database format. in the libc, getservent has been modified to first try to read the .cdb fil= es and fallback on reading the old .db file. (I'm not sure if it is worth keep= ing reading the old db format.) http://people.freebsd.org/~bapt/cdbrw.diff The plan after that is to get pw_util(3) directly generating a cdb file for pwd.db and spwd.db and modifiy pwd_mkdb(8) so that by default it uses the A= PI =66rom pw_util(3) and have a switch to fallback on creating in bdb format. I also plan to do the same for cap_mkdb(1) and getcap(3). With cdb querying is way faster (I don't have number but I can get some it needed) the size of the db is also way smaller: 64K /var/db/services.cdb 2,1M /var/db/services.db Any objection? regards, Bapt --EuxKj2iCbKjpUGkD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlJtoSQACgkQ8kTtMUmk6EzdcQCeJ0SyBOm02FcjNbq1cOUsyBjF NgsAn3V5SaFiFsgMKlnK+qczJt5Dq2Rw =zemp -----END PGP SIGNATURE----- --EuxKj2iCbKjpUGkD-- From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 28 21:22:17 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D853164F for ; Mon, 28 Oct 2013 21:22:17 +0000 (UTC) (envelope-from electreg@list.ru) Received: from fallback7.mail.ru (fallback7.mail.ru [94.100.176.135]) by mx1.freebsd.org (Postfix) with ESMTP id 558A22F71 for ; Mon, 28 Oct 2013 21:22:17 +0000 (UTC) Received: from f402.i.mail.ru (f402.i.mail.ru [185.5.136.73]) by fallback7.mail.ru (mPOP.Fallback_MX) with ESMTP id D2792E993754 for ; Tue, 29 Oct 2013 01:22:09 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=list.ru; s=mail; h=Content-Type:Message-ID:Reply-To:Date:Mime-Version:Subject:To:From; bh=4Hp1///UyJqLXBy4eMe2Anhy+Mqtg3ocXu/fLgr07LI=; b=MVdwsi9ZZrMpbuKPmaKpkxdTcV4BEy7W9n3tMcU17aEfqC6EdsZfhkPmCRCK64aNxp9uoQl/EgJRKVxQkb9gWO5Rk95eQzHIbJ+Dg9VSIdouyh95o9RL1UxX2iFK6SLIFiihUgIAgcEEI05vi3XVWuRz3yslww/TFKxH4Fha19M=; Received: from mail by f402.i.mail.ru with local (envelope-from ) id 1VauFz-0001OF-Pd for freebsd-hackers@freebsd.org; Tue, 29 Oct 2013 01:21:51 +0400 Received: from [188.17.208.165] by e.mail.ru with HTTP; Tue, 29 Oct 2013 01:21:51 +0400 From: =?UTF-8?B?QWxleGV5IEVnb3Jvdg==?= To: freebsd-hackers@freebsd.org Subject: =?UTF-8?B?Y2xvc2luZyBrcXVldWUgZGVzY3JpcHRvciBkb2Vzbid0IHJlbGVhc2UgYXNz?= =?UTF-8?B?b2NpYXRlZCBrZXJuZWwgcmVzb3VyY2VzPw==?= Mime-Version: 1.0 X-Mailer: Mail.Ru Mailer 1.0 X-Originating-IP: [188.17.208.165] Date: Tue, 29 Oct 2013 01:21:51 +0400 X-Priority: 3 (Normal) Message-ID: <1382995311.800352930@f402.i.mail.ru> X-Mras: Ok X-Spam: undefined Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: =?UTF-8?B?QWxleGV5IEVnb3Jvdg==?= List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 21:22:17 -0000 CkhlbGxvIGFsbCwKSSdtIHBvcnRpbmcgYXBwbGljYXRpb24gZnJvbSBMaW51eCB3aGljaCB1c2Vz IGxpYmFpbyBmb3IgYXN5bmMgZGlzayBJTy4KT24gRnJlZUJTRCB3ZSBhcmUgdXNpbmcga3F1ZXVl ICsgcG9zaXggQUlPLCBidXQgSSBkaXNjb3ZlcmVkIHRoYXQgY2xvc2luZyBrcXVldWUgZGVzY3Jp cHRvciBkb2Vzbid0IHJlbGVhc2UgYXNzb2NpYXRlZCBhaW8gcmVxdWVzdHMgLSBzeXNjdGwgdmFs dWUgdmZzLmFpby5udW1fcXVldWVfY291bnQga2VlcHMgZ3Jvd2luZyBlYWNoIHRpbWUgSSdtIGNs b3NlIGtxdWV1ZSBmZCB3aXRob3V0IHdhaXRpbmcgZm9yIGFpbyByZXF1ZXN0cyB0byBjb21wbGV0 ZSwgYW5kIHRoZW4gYXQgc29tZSBwb2ludCB3aGVuIGxpbWl0IGlzIHJlYWNoZWQgcHJvZ3JhbSBo YW5ncy4KUHJvYmxlbSBnZXR0aW5nIGhhcmRlciBjb25zaWRlcmluZyB0aGF0IEknbSBkb2luZyBJ TyBvbiByYXcgZGlzayBkZXZpY2UgYW5kIGNhbid0IGNhbmNlbCByZXF1ZXN0cyB3aXRoIGFpb19j YW5jZWwoMikuCklzIGl0IGEgYnVnPyBIb3cgY2FuIEkgcmVsZWFzZSB0aGlzIHJlcXVlc3RzIHdp dGhvdXQgdGVybWluYXRpbmcgcHJvY2VzcyBvciB3YWl0aW5nIGZvciBhbGwgcmVxdWVzdHMgdG8g Y29tcGxldGU/ClRoYW5rcy4KwqA= From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 28 22:07:47 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 495A3425 for ; Mon, 28 Oct 2013 22:07:47 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0A8882318 for ; Mon, 28 Oct 2013 22:07:46 +0000 (UTC) Received: by mail-qa0-f49.google.com with SMTP id i13so2489031qae.1 for ; Mon, 28 Oct 2013 15:07:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=pxFa+Uaq79G/YjslIHme0qLcXbkXouEugyeOj/YQ690=; b=EK9xKA94sAsDhGKQ44zn6rIk4ehNRAJR53f2aOcsSsXTf18iIbsZEtx279cJmeRL04 LVapcy7bHDwW7FIuA2zlBX1kykNk0CE072FhMKak7OsdYRiqoLVe5LR2/8mflosvh0SI MF986cKigqQzmEEYJ0W4LC6m+a33q1T/Of8CCtjuSIjQ+SqGVLOaoGjEfPWS88tAIPPv sfZs9MjqlpdQCe9d0tGN/suF4YkyHDR9eFuS8Q3v3CUuMWZsJ9XfJVBCTE5U7iga0Tev SeOVy4GtfU0WhSh182ljVtYOlDBYfv0woXSNrvMfx2UP9KktQM+tPRqLfZbe77uNSD5g 2alA== MIME-Version: 1.0 X-Received: by 10.224.36.201 with SMTP id u9mr32497661qad.76.1382998057595; Mon, 28 Oct 2013 15:07:37 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Mon, 28 Oct 2013 15:07:37 -0700 (PDT) In-Reply-To: <1382995311.800352930@f402.i.mail.ru> References: <1382995311.800352930@f402.i.mail.ru> Date: Mon, 28 Oct 2013 15:07:37 -0700 X-Google-Sender-Auth: 4QOXOlZq_GN5I6OVfk_YNWqDH3o Message-ID: Subject: Re: closing kqueue descriptor doesn't release associated kernel resources? From: Adrian Chadd To: Alexey Egorov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 22:07:47 -0000 Hi! Yes. The POSIX AIO API puts the responsibility on the programmer to correctly terminate requests: * aborting them with aio_cancel() (and it succeeding), or * waiting for them to complete. So yes, you're going to have to track them and correctly abort/complete the requests. Thanks, -adrian On 28 October 2013 14:21, Alexey Egorov wrote: > > Hello all, > I'm porting application from Linux which uses libaio for async disk IO. > On FreeBSD we are using kqueue + posix AIO, but I discovered that closing= kqueue descriptor doesn't release associated aio requests - sysctl value v= fs.aio.num_queue_count keeps growing each time I'm close kqueue fd without = waiting for aio requests to complete, and then at some point when limit is = reached program hangs. > Problem getting harder considering that I'm doing IO on raw disk device a= nd can't cancel requests with aio_cancel(2). > Is it a bug? How can I release this requests without terminating process = or waiting for all requests to complete? > Thanks. > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 29 10:33:43 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 523A0FD5 for ; Tue, 29 Oct 2013 10:33:43 +0000 (UTC) (envelope-from bounces+73574-4a99-freebsd-hackers=freebsd.org@sendgrid.me) Received: from o3.shared.sendgrid.net (o3.shared.sendgrid.net [208.117.48.85]) by mx1.freebsd.org (Postfix) with SMTP id F1E4E2A56 for ; Tue, 29 Oct 2013 10:33:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h=from:mime-version:to:subject:content-type:content-transfer-encoding; s=smtpapi; bh=ThRqXlIAA+CBPlERnPLUjRjAjF4=; b=wFnxXixXlvo6PqlXaG 02LxnLslLqW9emp9M/nqBLZWTJC03jpoLswv0pM4PvO7dVQnq1cxLd5p79OBDJDJ IrQQ/Zi2ahMCI1Cpnn0sdCRpt6/LQsYBc5Inxp1VRVxgp/aRki7UqAQ/D2xW46tB 5xraGsVtAj0WWhVji+pYg5xkw= Received: by mf91 with SMTP id mf91.3806.526F8F057 Tue, 29 Oct 2013 10:33:41 +0000 (GMT) Received: from mail.tarsnap.com (unknown [10.60.208.13]) by mi4 (SG) with ESMTP id 14203c6aedd.3ac.8f71e for ; Tue, 29 Oct 2013 10:33:41 +0000 (UTC) Received: (qmail 32855 invoked from network); 29 Oct 2013 10:33:40 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 29 Oct 2013 10:33:40 -0000 Received: (qmail 44255 invoked from network); 29 Oct 2013 10:32:19 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 29 Oct 2013 10:32:19 -0000 Message-ID: <526F8EB3.1040205@freebsd.org> Date: Tue, 29 Oct 2013 03:32:19 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Automated submission of kernel panic reports X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SG-EID: W2XBZA0V/n0voZZ6SjDkgjXvzGvkLIaljy40FLIRIHTVMXCc7ynl2WKQUz0qqp0ckgz9Q81xAdQCWzInfKBGZ/w2c+4rsA4dwUujGv1DycGzkRtt/PsfPaQvBDr6CanUbglQmwvPKtl/5AyrlxSuLOdNTopS0ISIl6s5LikkfkA= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 10:33:43 -0000 Hi all, I've written some code for automatically submitting kernel panic reports, and I'd like some feedback before I place it into the ports tree. I am aware of a recent Summer of Code project in this area, but I understand that it focused mainly on the processing of kernel panics after they have been collected (identifying matching backtraces, etc.) rather than the initial collection of panics. In my work on FreeBSD/EC2 I have been collecting panics for a couple of years, and despite the small install base (I estimate about 100 EC2 instances running FreeBSD at any given time) it has proven useful, for example by allowing me to identify that the ARP bug fixed in r214675 was causing severe stability issues in the EC2 environment. My current code is an rc.d script which, running after savecore, checks to see if the most recent panic (if any) has been reported yet. If not, it gathers the dump header (/var/crash/info.N) and a backtrace for the panic. If ${panicmail_autosubmit} is set to YES, this information is encrypted and submitted via email. The email which is sent looks like this: http://pastebin.com/AaCuxvDg If ${panicmail_autosubmit} is set to NO, an email is sent to root containing the panic data in both decrypted and encrypted forms. The system administrator can then review the information and decide whether to allow it to be submitted. Such emails look like this: http://pastebin.com/w18pXah8 The code is in http://svnweb.freebsd.org/base/user/cperciva/panicmail/ and it uses my FreeBSD-base-system-only public-key encryption code: http://svnweb.freebsd.org/base/user/cperciva/pkesh/ My plan is to get this into the ports tree, encourage people to install and enable it, and then assuming it proves useful see it added into the FreeBSD base system some day. At least initially I'd have panics coming to me, using an encryption key which I hold; if/when it enters the FreeBSD base system, some decision would need to be made (by core?) as to who should have access to the panics. Comments? -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 29 10:44:16 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B7E47378 for ; Tue, 29 Oct 2013 10:44:16 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from mail.embedded-brains.de (host-82-135-62-35.customer.m-online.net [82.135.62.35]) by mx1.freebsd.org (Postfix) with ESMTP id 2BCB52B28 for ; Tue, 29 Oct 2013 10:44:15 +0000 (UTC) Received: by mail.embedded-brains.de (Postfix, from userid 65534) id 2E087652CF6; Tue, 29 Oct 2013 11:35:09 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on fidibusdmz X-Spam-Level: X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from [192.168.100.11] (unknown [192.168.100.11]) by mail.embedded-brains.de (Postfix) with ESMTP id 1D0DB65253A for ; Tue, 29 Oct 2013 11:35:09 +0100 (CET) Message-ID: <526F8F58.1090307@embedded-brains.de> Date: Tue, 29 Oct 2013 11:35:04 +0100 From: Sebastian Huber User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "freebsd-hackers@freebsd.org" Subject: soo_close() vs. filt_soread() Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 10:44:16 -0000 Hello, I port currently the FreeBSD network stack to a real-time operating system. The problem described below probably does not happen in a real FreeBSD kernel. I have the following test case: static void test_kqueue_close(test_context *ctx) { /* The cfd is some socket with a connected TCP stream */ int cfd = ctx->cfd; int kq; struct kevent change; struct kevent event; const struct timespec *timeout = NULL; int rv; ssize_t n; puts("test kqueue close"); assert(ctx->cfd >= 0); kq = kqueue(); assert(kq >= 0); EV_SET(&change, cfd, EVFILT_READ, EV_ADD | EV_ENABLE, 0, 0, TEST_UDATA); rv = kevent(kq, &change, 1, NULL, 0, timeout); assert(rv == 0); set_non_blocking(cfd, 1); do { errno = 0; n = read(cfd, &ctx->buf[0], sizeof(ctx->buf)); if (n == -1) { assert(errno = EAGAIN); } } while (n > 0); /* This tells some background entity that we want to close cfd once kevent blocks */ send_events(ctx, EVENT_CLOSE); assert(ctx->cfd >= 0); rv = kevent(kq, NULL, 0, &event, 1, timeout); assert(rv == 1); assert(event.ident == cfd); assert(event.filter == EVFILT_READ); assert(event.flags == 0); assert(event.fflags == 0); assert(event.data == 0); assert(event.udata == TEST_UDATA); assert(ctx->cfd == -1); rv = close(kq); assert(rv == 0); } This test registers a read event and then blocks for this event. Once the current thread blocked, someone will delete the corresponding socket. I have now a NULL pointer access. The socket close looks like this: /* * API socket close on file pointer. We call soclose() to close the socket * (including initiating closing protocols). soclose() will sorele() the * file reference but the actual socket will not go away until the socket's * ref count hits 0. */ /* ARGSUSED */ int soo_close(struct file *fp, struct thread *td) { int error = 0; struct socket *so; so = fp->f_data; fp->f_ops = &badfileops; fp->f_data = NULL; if (so) error = soclose(so); return (error); } Please note that fp->f_data is set to NULL. The close operation will end up in: /*ARGSUSED*/ static int filt_soread(struct knote *kn, long hint) { struct socket *so; so = kn->kn_fp->f_data; SOCKBUF_LOCK_ASSERT(&so->so_rcv); kn->kn_data = so->so_rcv.sb_cc - so->so_rcv.sb_ctl; if (so->so_rcv.sb_state & SBS_CANTRCVMORE) { kn->kn_flags |= EV_EOF; kn->kn_fflags = so->so_error; return (1); } else if (so->so_error) /* temporary udp error */ return (1); else if (kn->kn_sfflags & NOTE_LOWAT) return (kn->kn_data >= kn->kn_sdata); else return (so->so_rcv.sb_cc >= so->so_rcv.sb_lowat); } Here so == NULL, due to soo_close(). Breakpoint 11, filt_soread (kn=0x46ff74, hint=0) at freebsd/sys/kern/uipc_socket.c:3147 3147 so = kn->kn_fp->f_data; (gdb) p so $4 = (struct socket *) 0x0 (gdb) p kn->kn_ptr.p_fp $5 = (struct file *) 0x32cec8 (gdb) where #0 filt_soread (kn=0x46ff74, hint=0) at freebsd/sys/kern/uipc_socket.c:3147 #1 0x0010506e in knote (list=0x3f1190, hint=0, lockflags=1) at freebsd/sys/kern/kern_event.c:1957 #2 0x00191a60 in sowakeup (so=0x3f1134, sb=0x3f1188) at freebsd/sys/kern/uipc_sockbuf.c:191 #3 0x00127afe in soisdisconnecting (so=0x3f1134) at freebsd/sys/kern/uipc_socket.c:3341 #4 0x00153cca in tcp_disconnect (tp=0x3f75ac) at freebsd/sys/netinet/tcp_usrreq.c:1508 #5 0x00152b30 in tcp_usr_disconnect (so=0x3f1134) at freebsd/sys/netinet/tcp_usrreq.c:556 #6 0x00124754 in sodisconnect (so=0x3f1134) at freebsd/sys/kern/uipc_socket.c:816 #7 0x00124384 in soclose (so=0x3f1134) at freebsd/sys/kern/uipc_socket.c:664 #8 0x00128886 in soo_close (fp=0x32cec8, td=0x0) at freebsd/sys/kern/sys_socket.c:452 Is this an illegal kevent() use case? Are there some means that prevent this sequence in a real FreeBSD kernel? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 29 11:12:55 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3FA79BBF for ; Tue, 29 Oct 2013 11:12:55 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F126B2CD0 for ; Tue, 29 Oct 2013 11:12:54 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Vb7E4-0003uU-Jt for freebsd-hackers@freebsd.org; Tue, 29 Oct 2013 12:12:44 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 29 Oct 2013 12:12:44 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 29 Oct 2013 12:12:44 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Subject: Re: Automated submission of kernel panic reports Date: Tue, 29 Oct 2013 12:12:35 +0100 Lines: 35 Message-ID: References: <526F8EB3.1040205@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VnvXwicIglUX5FCdfA7aP6IWtSmQuEAmS" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 In-Reply-To: <526F8EB3.1040205@freebsd.org> X-Enigmail-Version: 1.5.2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 11:12:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VnvXwicIglUX5FCdfA7aP6IWtSmQuEAmS Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 29/10/2013 11:32, Colin Percival wrote: > If ${panicmail_autosubmit} is set to YES, this information is encrypted= and > submitted via email. The email which is sent looks like this: > http://pastebin.com/AaCuxvDg I haven't tried it, but there's NetPGP (http://www.netpgp.com/) which can be used to generate standard PGP-formatted messages instead of using a custom format. What do you think about it? --VnvXwicIglUX5FCdfA7aP6IWtSmQuEAmS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlJvmCNfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDYxNDE4MkQ3ODMwNDAwMDJFRUIzNDhFNUZE MDhENTA2M0RGRjFEMkMACgkQ/QjVBj3/HSwH5ACeIPvNM0ImTF23mJcGNoc3bGGC MqgAnRmcsk8XrUDjN7mO8YrLjzdcQAP8 =sIMu -----END PGP SIGNATURE----- --VnvXwicIglUX5FCdfA7aP6IWtSmQuEAmS-- From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 29 16:53:03 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C1F3E9A for ; Tue, 29 Oct 2013 16:53:03 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mail.egr.msu.edu (hill.egr.msu.edu [35.9.37.162]) by mx1.freebsd.org (Postfix) with ESMTP id 9361724CD for ; Tue, 29 Oct 2013 16:53:03 +0000 (UTC) Received: from hill (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id 263E82D531 for ; Tue, 29 Oct 2013 12:53:02 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by hill (hill.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8NZTcJ0BiAb for ; Tue, 29 Oct 2013 12:53:02 -0400 (EDT) Received: from EGR authenticated sender Message-ID: <526FE7ED.5000903@egr.msu.edu> Date: Tue, 29 Oct 2013 12:53:01 -0400 From: Adam McDougall User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Automated submission of kernel panic reports References: <526F8EB3.1040205@freebsd.org> In-Reply-To: <526F8EB3.1040205@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 16:53:03 -0000 On 10/29/2013 06:32, Colin Percival wrote: > Hi all, > > I've written some code for automatically submitting kernel panic reports, > and I'd like some feedback before I place it into the ports tree. > > If ${panicmail_autosubmit} is set to NO, an email is sent to root containing > the panic data in both decrypted and encrypted forms. The system administrator > can then review the information and decide whether to allow it to be submitted. > Such emails look like this: > http://pastebin.com/w18pXah8 > > The code is in > http://svnweb.freebsd.org/base/user/cperciva/panicmail/ > and it uses my FreeBSD-base-system-only public-key encryption code: > http://svnweb.freebsd.org/base/user/cperciva/pkesh/ > > My plan is to get this into the ports tree, encourage people to install and > enable it, and then assuming it proves useful see it added into the FreeBSD > base system some day. At least initially I'd have panics coming to me, using > an encryption key which I hold; if/when it enters the FreeBSD base system, > some decision would need to be made (by core?) as to who should have access > to the panics. > > Comments? > The first thing that comes to mind is privacy so I looked at the information being submitted. Would it be possible to replace the hostname(s) and kernel config paths in the report with a hash by default? That way a site could still match up reports to internal hostnames without revealing anything specific about the source system. The hostname is only needed to differentiate sources and is not guaranteed to be unique anyway. Just thinking ahead about the information being obtained and reducing what is transmitted/stored in case it somehow falls into the wrong hands at some point in the future. Aside from that, I like it and would consider running it myself as long as I have appropriate control over the content. Thanks. From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 29 20:47:03 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C34C75D7 for ; Tue, 29 Oct 2013 20:47:03 +0000 (UTC) (envelope-from trev@larock.ca) Received: from dpmailmta01.doteasy.com (dpmailmta01-17.doteasy.com [65.61.218.17]) by mx1.freebsd.org (Postfix) with ESMTP id 8F936258E for ; Tue, 29 Oct 2013 20:47:03 +0000 (UTC) Received: from dpmail22.doteasy.com ([192.168.101.22]) by dpmailrp04.doteasy.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r9TKUfDl008660 for ; Tue, 29 Oct 2013 13:30:41 -0700 Received: from mail-lb0-f177.google.com [209.85.217.177] by dpmail22.doteasy.com with SMTP; Tue, 29 Oct 2013 13:30:34 -0700 Received: by mail-lb0-f177.google.com with SMTP id u14so476759lbd.36 for ; Tue, 29 Oct 2013 13:30:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:date:message-id:subject:from:to:content-type; bh=ln7LjdYaPbRPKW549WXzLoXBKcKtAdsul32mSaN7mZ4=; b=jP4qItMrO89jsXghBkGOFiY8QSOvpDe5/0NMX1kT/8/ZFi8U+ibQ5QkwYdeWBTsyn1 YzUwQdJ/qcaESoBqd/PI4JgOrcQXqMkcZPcqStOzWMHpyjRMqskhzHZuG0tc3jtsXaxH oU13BEdEsdxED1o4oUeYZcAxAay2iOs/z9uQ88yUAuKOILggCX7F8AC+Uyd37s5DWBS3 T8U4mLpKuirBBtWQCYv8r372UcLiJBRBFxsGVOQI/FD662fYi+j2wSoDGypIdarG201t lGSg9Vo6IngWM++83dkRQMqO9EKjVaGdGOLIWnLSOguvn82LH8A86/dkbGUHc6wqciS/ CGQA== MIME-Version: 1.0 X-Received: by 10.152.10.34 with SMTP id f2mr69264lab.64.1383078628855; Tue, 29 Oct 2013 13:30:28 -0700 (PDT) Received: by 10.112.35.197 with HTTP; Tue, 29 Oct 2013 13:30:28 -0700 (PDT) Date: Tue, 29 Oct 2013 16:30:28 -0400 Message-ID: Subject: AES-GCM in kernel From: "trev@larock.ca" To: freebsd-hackers@freebsd.org X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN, base:default) X-Spam-Score: 0.10 () [Hold at 5.00] HTML_MESSAGE:0.001, RDNS_NONE:0.1, TO_NO_BRKTS_NORDNS:0.001 X-CanIt-Geo: No geolocation information available for 192.168.101.22 X-CanItPRO-Stream: base:default X-Canit-Stats-ID: 05KH8uFE2 - b69c619a4a62 - 20131029 X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.101.84 X-Originating-IP: 192.168.101.84 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 20:47:03 -0000 Hi, I was interested to know more about AES-GCM plans for the kernel. I have seen a few posts about patches that might get committed but there didn't seem to be further discussion. Any related info/roadmap plans? Thanks, Trev Larock _______________________________________________________ Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting http://www.doteasy.com From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 29 21:11:46 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0DCA9D84; Tue, 29 Oct 2013 21:11:46 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2B30A2803; Tue, 29 Oct 2013 21:11:44 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA15681; Tue, 29 Oct 2013 23:11:43 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VbGZj-0005x6-9I; Tue, 29 Oct 2013 23:11:43 +0200 Message-ID: <5270246B.6070105@FreeBSD.org> Date: Tue, 29 Oct 2013 23:11:07 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: dtrace@FreeBSD.org Subject: sdt "sname" removal X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 21:11:46 -0000 I never understood why FreeBSD SDT as opposed to upstream SDT requires the same or almost the same probe name to be specified twice. This seems to be silly and a little bit error-prone. In other words, I do not see any reason not to re-use the original upstream trick where double underscore in a providers name in the C code gets converted to a single dash in a DTrace provider name. [*] So here is my take at that: http://people.freebsd.org/~avg/sdt-sname-removal.diff An inline preview of the change: -SDT_PROBE_DEFINE1(priv, kernel, priv_check, priv_ok, priv-ok, "int"); -SDT_PROBE_DEFINE1(priv, kernel, priv_check, priv_err, priv-err, "int"); +SDT_PROBE_DEFINE1(priv, kernel, priv_check, priv__ok, "int"); +SDT_PROBE_DEFINE1(priv, kernel, priv_check, priv__err, "int"); It's possible that I missed some places where old style SDT_PROBE_DEFINE macros are used or where an old probe name is used with SDT_PROBE_ARGTYPE or SDT_PROBE. Please test, review, comment, etc. Thank you! -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 29 22:25:17 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 893A1C87 for ; Tue, 29 Oct 2013 22:25:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0B86B2CE1 for ; Tue, 29 Oct 2013 22:25:16 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r9TMP8X3011752; Wed, 30 Oct 2013 00:25:08 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r9TMP8X3011752 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r9TMP8Q9011746; Wed, 30 Oct 2013 00:25:08 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 30 Oct 2013 00:25:08 +0200 From: Konstantin Belousov To: Sebastian Huber Subject: Re: soo_close() vs. filt_soread() Message-ID: <20131029222508.GA59496@kib.kiev.ua> References: <526F8F58.1090307@embedded-brains.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NgLNC/STdjXvE6Rt" Content-Disposition: inline In-Reply-To: <526F8F58.1090307@embedded-brains.de> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 22:25:17 -0000 --NgLNC/STdjXvE6Rt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 29, 2013 at 11:35:04AM +0100, Sebastian Huber wrote: > Hello, >=20 > I port currently the FreeBSD network stack to a real-time operating syste= m.=20 > The problem described below probably does not happen in a real FreeBSD ke= rnel.=20 > I have the following test case: >=20 > static void > test_kqueue_close(test_context *ctx) > { > /* The cfd is some socket with a connected TCP stream */ > int cfd =3D ctx->cfd; > int kq; > struct kevent change; > struct kevent event; > const struct timespec *timeout =3D NULL; > int rv; > ssize_t n; >=20 > puts("test kqueue close"); >=20 > assert(ctx->cfd >=3D 0); >=20 > kq =3D kqueue(); > assert(kq >=3D 0); >=20 > EV_SET(&change, cfd, EVFILT_READ, EV_ADD | EV_ENABLE, 0, 0, > TEST_UDATA); >=20 > rv =3D kevent(kq, &change, 1, NULL, 0, timeout); > assert(rv =3D=3D 0); >=20 > set_non_blocking(cfd, 1); >=20 > do { > errno =3D 0; > n =3D read(cfd, &ctx->buf[0], sizeof(ctx->buf)); > if (n =3D=3D -1) { > assert(errno =3D EAGAIN); > } > } while (n > 0); >=20 >=20 > /* This tells some background entity that we want to close cfd once keve= nt=20 > blocks */ > send_events(ctx, EVENT_CLOSE); >=20 > assert(ctx->cfd >=3D 0); >=20 > rv =3D kevent(kq, NULL, 0, &event, 1, timeout); > assert(rv =3D=3D 1); > assert(event.ident =3D=3D cfd); > assert(event.filter =3D=3D EVFILT_READ); > assert(event.flags =3D=3D 0); > assert(event.fflags =3D=3D 0); > assert(event.data =3D=3D 0); > assert(event.udata =3D=3D TEST_UDATA); >=20 > assert(ctx->cfd =3D=3D -1); >=20 > rv =3D close(kq); > assert(rv =3D=3D 0); > } >=20 > This test registers a read event and then blocks for this event. Once th= e=20 > current thread blocked, someone will delete the corresponding socket. I = have=20 > now a NULL pointer access. The socket close looks like this: >=20 > /* > * API socket close on file pointer. We call soclose() to close the soc= ket > * (including initiating closing protocols). soclose() will sorele() the > * file reference but the actual socket will not go away until the socke= t's > * ref count hits 0. > */ > /* ARGSUSED */ > int > soo_close(struct file *fp, struct thread *td) > { > int error =3D 0; > struct socket *so; >=20 > so =3D fp->f_data; > fp->f_ops =3D &badfileops; > fp->f_data =3D NULL; >=20 > if (so) > error =3D soclose(so); > return (error); > } >=20 > Please note that fp->f_data is set to NULL. >=20 > The close operation will end up in: >=20 > /*ARGSUSED*/ > static int > filt_soread(struct knote *kn, long hint) > { > struct socket *so; >=20 > so =3D kn->kn_fp->f_data; > SOCKBUF_LOCK_ASSERT(&so->so_rcv); >=20 > kn->kn_data =3D so->so_rcv.sb_cc - so->so_rcv.sb_ctl; > if (so->so_rcv.sb_state & SBS_CANTRCVMORE) { > kn->kn_flags |=3D EV_EOF; > kn->kn_fflags =3D so->so_error; > return (1); > } else if (so->so_error) /* temporary udp error */ > return (1); > else if (kn->kn_sfflags & NOTE_LOWAT) > return (kn->kn_data >=3D kn->kn_sdata); > else > return (so->so_rcv.sb_cc >=3D so->so_rcv.sb_lowat); > } >=20 > Here so =3D=3D NULL, due to soo_close(). >=20 > Breakpoint 11, filt_soread (kn=3D0x46ff74, hint=3D0) at=20 > freebsd/sys/kern/uipc_socket.c:3147 > 3147 so =3D kn->kn_fp->f_data; > (gdb) p so > $4 =3D (struct socket *) 0x0 > (gdb) p kn->kn_ptr.p_fp > $5 =3D (struct file *) 0x32cec8 > (gdb) where > #0 filt_soread (kn=3D0x46ff74, hint=3D0) at freebsd/sys/kern/uipc_socket= =2Ec:3147 > #1 0x0010506e in knote (list=3D0x3f1190, hint=3D0, lockflags=3D1) at=20 > freebsd/sys/kern/kern_event.c:1957 > #2 0x00191a60 in sowakeup (so=3D0x3f1134, sb=3D0x3f1188) at=20 > freebsd/sys/kern/uipc_sockbuf.c:191 > #3 0x00127afe in soisdisconnecting (so=3D0x3f1134) at=20 > freebsd/sys/kern/uipc_socket.c:3341 > #4 0x00153cca in tcp_disconnect (tp=3D0x3f75ac) at=20 > freebsd/sys/netinet/tcp_usrreq.c:1508 > #5 0x00152b30 in tcp_usr_disconnect (so=3D0x3f1134) at=20 > freebsd/sys/netinet/tcp_usrreq.c:556 > #6 0x00124754 in sodisconnect (so=3D0x3f1134) at freebsd/sys/kern/uipc_s= ocket.c:816 > #7 0x00124384 in soclose (so=3D0x3f1134) at freebsd/sys/kern/uipc_socket= =2Ec:664 > #8 0x00128886 in soo_close (fp=3D0x32cec8, td=3D0x0) at=20 > freebsd/sys/kern/sys_socket.c:452 >=20 > Is this an illegal kevent() use case? Are there some means that prevent = this=20 > sequence in a real FreeBSD kernel? When file descriptor gets closed, kevent subsystem is notified first and clears knotes related to the filedescriptor (important, not the file) being closed. You could see this in the closefp() function calling knote_fdclose(). Since files are referenced and destroyed only when the last reference vanishes, and filedescriptor holds a reference on the file, file (which is socket in your case) cannot go away until knotes are expunged. There are some corner cases, when knotes are really attached to objects with different life-cycle, like vnodes, but I believe the description above should be accurate enough for sockets. If there is a problem in the FreeBSD code and you could produce a test case, do not hesitate to send it to me. Thank you. --NgLNC/STdjXvE6Rt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJScDXDAAoJEJDCuSvBvK1BTT8P/jK5Kfv5IzM3to+MIZ0u8mVR 5BsYD49Gh4HR/l7/ZQs3a4JnmUAuMtiRItTgXFFgEAFWOgFXHlc3H9zxD3HN4a51 8bozYg+3IIh111RqEUYEfpN+SBEr9LggPGl349O2oAVw5ueLxWdWdMV7IIT63prR aSqp+Xb8XDJ8SitIeB7lyetGQfdpn7iQEQyuVu6NsK0ZNRngAIlUCD6cYTWBtEG4 ESCoCj9Jx9WoJhCcJigF2yyX1NWrkgdFaSXiK/Ob1L4kYH2Z/AOmEC9E1fnRdAxJ d7Xcdy4lW+9IQ5syPE1qZn7wJX7AF7rcJUdFWIm+tlMv2Jgybs3LJq9Hdirugws1 IIeCIyw8Yk14xkN8Gh7OGW9shh1tdpQRvXrSt0xoVXbMy3NusnR6yXwAgyCE7Lv1 csGQK5GanC0aoKY47Uq2xrAimd4Op75CT/mxh545SbGjSV6lAKGUS5Z2H6zVvclI 84NujYrqjjj/GtetS34SvaJinSQE20O74OxVd/KT9jkmHNLjBi5LaMAmMJJgFGPE MC08Ef4zcSqNN6WmZmghkGW7gLPZ5O+GvLoIxdKIx8SzQlXX6wTW6pHXuN1Tgv+w /SUEityppiRiDe8Wihb5zNfeQFjbLzMDBdTpZW6CtyyhtNSif89WtmpsK9XCY4Fq p57UxPOxeqyokeiYMf2O =ex/F -----END PGP SIGNATURE----- --NgLNC/STdjXvE6Rt-- From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 29 22:59:08 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CC8A7661 for ; Tue, 29 Oct 2013 22:59:08 +0000 (UTC) (envelope-from trev@larock.ca) Received: from dpmailmta06.doteasy.com (dpmailmta06-28.doteasy.com [65.61.219.108]) by mx1.freebsd.org (Postfix) with ESMTP id A1C762EB9 for ; Tue, 29 Oct 2013 22:59:08 +0000 (UTC) Received: from dpmail22.doteasy.com ([192.168.101.22]) by dpmailrp04.doteasy.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r9TMgoZF028997 for ; Tue, 29 Oct 2013 15:42:50 -0700 Received: from [66.129.241.11] by dpmail22.doteasy.com via HTTP; Tue, 29 Oct 2013 15:42:43 -0700 MIME-Version: 1.0 Date: Tue, 29 Oct 2013 15:42:43 -0700 Subject: AES-GCM In kernel From: "Trevor Larock" To: CC: Message-ID: <924596cfc6a64d8f881d90bfb14d8beb@dpmail22.doteasy.com> X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN, base:default) X-Spam-Score: 0.10 () [Hold at 5.00] HTML_MESSAGE:0.001,RDNS_NONE:0.1 X-CanIt-Geo: No geolocation information available for 192.168.101.22 X-CanItPRO-Stream: base:default X-Canit-Stats-ID: 05KHaGOLe - a2d4d4637294 - 20131029 X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.101.84 X-Originating-IP: 192.168.101.84 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: trev@larock.ca List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 22:59:08 -0000 =0D=0AHi,=0D=0AI was interested to know more about AES-GCM plans for the ke= rnel.=0D=0AI have seen a few posts about patches that might get committed b= ut =0D=0Athere didn't seem to be further discussion. Any related info/roadm= ap plans?=0D=0A=0D=0AThanks,Trev Larock _______________________________________________________ Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting http://www.doteasy.com From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 29 23:14:21 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3322CA47 for ; Tue, 29 Oct 2013 23:14:21 +0000 (UTC) (envelope-from bounces+73574-4a99-freebsd-hackers=freebsd.org@sendgrid.me) Received: from o3.shared.sendgrid.net (o3.shared.sendgrid.net [208.117.48.85]) by mx1.freebsd.org (Postfix) with SMTP id DB2A12F99 for ; Tue, 29 Oct 2013 23:14:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h=from:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpapi; bh=Fw8Gz41eB7OHabfdbMqiHV3j/xY=; b=jKPGD4tzxTQZOwKBi4 O4OJlro5Qjf/ZRxB1zVkHtQ0aFQvn7vHG12plcyMdJ59tqv0+1b/kTTHTVNPjp7t zS58SETXMxKA7rc3o5PKKAfisurOjUHnOO8V92q5f/ef3EjyaLwEZu4UbI8CRT6Z TX91ltW9Lq9EJv6wQzzcemdEA= Received: by mf40.sendgrid.net with SMTP id mf40.4901.5270414B9 Tue, 29 Oct 2013 23:14:19 +0000 (GMT) Received: from mail.tarsnap.com (unknown [10.60.208.15]) by mi16 (SG) with ESMTP id 142067f0ff4.1c70.25bc3 for ; Tue, 29 Oct 2013 23:14:19 +0000 (UTC) Received: (qmail 56936 invoked from network); 29 Oct 2013 23:14:18 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 29 Oct 2013 23:14:18 -0000 Received: (qmail 49487 invoked from network); 29 Oct 2013 23:12:54 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 29 Oct 2013 23:12:54 -0000 Message-ID: <527040F6.6080309@freebsd.org> Date: Tue, 29 Oct 2013 16:12:54 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Ivan Voras , freebsd-hackers@freebsd.org Subject: Re: Automated submission of kernel panic reports References: <526F8EB3.1040205@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SG-EID: W2XBZA0V/n0voZZ6SjDkgjXvzGvkLIaljy40FLIRIHTVMXCc7ynl2WKQUz0qqp0cvRDC0oXYcLIwIGdSvjJbUGi44CeHoRqV6/d5vXox7vNXHrMMGGhpDD3ol2iXY9YRw1SFlhchZArbjPmHabozrzj+5W8uYNPZE2erpVwR1xI= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 23:14:21 -0000 On 10/29/13 04:12, Ivan Voras wrote: > On 29/10/2013 11:32, Colin Percival wrote: >> If ${panicmail_autosubmit} is set to YES, this information is encrypted >> and submitted via email. The email which is sent looks like this: >> http://pastebin.com/AaCuxvDg > > I haven't tried it, but there's NetPGP (http://www.netpgp.com/) which can > be used to generate standard PGP-formatted messages instead of using a > custom format. What do you think about it? If you need the full functionality of PGP, it looks great. But for this particular purpose I'd prefer to have 71 lines rather than 40,000 lines. The same logic is why freebsd-update and portsnap use 'openssl rsautl' directly instead of gpg/netpgp/etc. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 29 23:27:11 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 69CA7E16 for ; Tue, 29 Oct 2013 23:27:11 +0000 (UTC) (envelope-from bounces+73574-4a99-freebsd-hackers=freebsd.org@sendgrid.me) Received: from o3.shared.sendgrid.net (o3.shared.sendgrid.net [208.117.48.85]) by mx1.freebsd.org (Postfix) with SMTP id 110B72083 for ; Tue, 29 Oct 2013 23:27:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h=from:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpapi; bh=Jbyo7HG4LlH57Cbu0hg+Lq08yyg=; b=aywAQCVvbynX/puQE1 i1PTYKi+OCPw3n6mhLGV1XOObFXIC8nA51GS0qGgcS0fy9bY2A8KgBENAjxixMvD QQHzvHebcZ7vR50w969YGyFEW+XdwmMRMgT2OuwnrBt/rEJcmcJWpd7ntZIPC70D VTfBEluvLCSOfJfjgt19P8vWA= Received: by mf72 with SMTP id mf72.9252.5270444E1 Tue, 29 Oct 2013 23:27:10 +0000 (GMT) Received: from mail.tarsnap.com (unknown [10.60.208.13]) by mi1 (SG) with ESMTP id 142068ad0d9.2753.19cdd for ; Tue, 29 Oct 2013 23:27:10 +0000 (UTC) Received: (qmail 57330 invoked from network); 29 Oct 2013 23:27:07 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 29 Oct 2013 23:27:07 -0000 Received: (qmail 49557 invoked from network); 29 Oct 2013 23:25:42 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 29 Oct 2013 23:25:42 -0000 Message-ID: <527043F6.7070802@freebsd.org> Date: Tue, 29 Oct 2013 16:25:42 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Adam McDougall , freebsd-hackers@freebsd.org Subject: Re: Automated submission of kernel panic reports References: <526F8EB3.1040205@freebsd.org> <526FE7ED.5000903@egr.msu.edu> In-Reply-To: <526FE7ED.5000903@egr.msu.edu> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SG-EID: W2XBZA0V/n0voZZ6SjDkgjXvzGvkLIaljy40FLIRIHTVMXCc7ynl2WKQUz0qqp0cadKHvVLv2tvFWzmLlUy99MfckxfQtwKPeOK1+8vov3I1gU0Xe3b6lbKzuJy4D3sB5NMfxbup52dqfZUQbTll3Dg1H9dCe82x2pBmniLgs8w= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 23:27:11 -0000 On 10/29/13 09:53, Adam McDougall wrote: > On 10/29/2013 06:32, Colin Percival wrote: >> If ${panicmail_autosubmit} is set to NO, an email is sent to root containing >> the panic data in both decrypted and encrypted forms. The system administrator >> can then review the information and decide whether to allow it to be submitted. >> Such emails look like this: >> http://pastebin.com/w18pXah8 >> >> Comments? > > The first thing that comes to mind is privacy so I looked at the > information being submitted. Would it be possible to replace the > hostname(s) and kernel config paths in the report with a hash by > default? That way a site could still match up reports to internal > hostnames without revealing anything specific about the source system. > The hostname is only needed to differentiate sources and is not > guaranteed to be unique anyway. Just thinking ahead about the > information being obtained and reducing what is transmitted/stored in > case it somehow falls into the wrong hands at some point in the future. > Aside from that, I like it and would consider running it myself as long > as I have appropriate control over the content. Thanks. The hostname could be filtered, but depending on how the panic report is submitted there's a good chance that it would be leaked anyway via email headers, so I figured it was better to make it obvious that it was being sent. The kernel config path I think will be very useful to have when it comes to tracking down the cause of a panic -- if there's a panic which keeps on happening with kernels named "DTRACE" but not kernels named "GENERIC", it give us a hint of where to look. I considered including the entire output of `sysctl -n kern.conftxt` but decided that might be too intrusive. Note: The purpose of the encryption is to protect "private" information in these reports from becoming public -- my intention is that access to the raw reports would be limited to a select group within the project. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 30 09:48:34 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 64F349EA for ; Wed, 30 Oct 2013 09:48:34 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from mail.embedded-brains.de (host-82-135-62-35.customer.m-online.net [82.135.62.35]) by mx1.freebsd.org (Postfix) with ESMTP id 1E00D21DB for ; Wed, 30 Oct 2013 09:48:33 +0000 (UTC) Received: by mail.embedded-brains.de (Postfix, from userid 65534) id E0C47652CF6; Wed, 30 Oct 2013 10:48:29 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on fidibusdmz X-Spam-Level: X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from [192.168.100.11] (unknown [192.168.100.11]) by mail.embedded-brains.de (Postfix) with ESMTP id ECF2665253A; Wed, 30 Oct 2013 10:48:27 +0100 (CET) Message-ID: <5270D5EB.4060004@embedded-brains.de> Date: Wed, 30 Oct 2013 10:48:27 +0100 From: Sebastian Huber User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: soo_close() vs. filt_soread() References: <526F8F58.1090307@embedded-brains.de> <20131029222508.GA59496@kib.kiev.ua> In-Reply-To: <20131029222508.GA59496@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 09:48:34 -0000 On 2013-10-29 23:25, Konstantin Belousov wrote: > On Tue, Oct 29, 2013 at 11:35:04AM +0100, Sebastian Huber wrote: [...] >> Are there some means that prevent this >> sequence in a real FreeBSD kernel? > > When file descriptor gets closed, kevent subsystem is notified first > and clears knotes related to the filedescriptor (important, not the > file) being closed. You could see this in the closefp() function calling > knote_fdclose(). Since files are referenced and destroyed only when the > last reference vanishes, and filedescriptor holds a reference on the > file, file (which is socket in your case) cannot go away until knotes > are expunged. > > There are some corner cases, when knotes are really attached to objects > with different life-cycle, like vnodes, but I believe the description > above should be accurate enough for sockets. [...] Thanks for the hints. I missed this knote_fdclose() completely. Similar test cases worked for select() and poll() since they use the file descriptor index. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 30 10:17:37 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 29184625 for ; Wed, 30 Oct 2013 10:17:37 +0000 (UTC) (envelope-from nkoch@demig.de) Received: from h949823.serverkompetenz.net (demig.de [85.214.63.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5769223EB for ; Wed, 30 Oct 2013 10:17:35 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=demig.de; b=mnlkZtWs8o17TGWvwEoYeyZ1gnhrfhzr1l6Cqa2oVpNMbpwso2xUsCQJ4QHQlxO+HjuPxPe8FtrluHXtV++YXtiivKi0k+AMWdcSq2BIcCNFoBHDWtiYSA0xespQAGvn; h=Received:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Scanned-By; Received: (qmail 21632 invoked from network); 30 Oct 2013 11:10:51 +0100 Received: from ip-84-119-92-252.unity-media.net (HELO firewall.demig.intra) (84.119.92.252) by demig.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 30 Oct 2013 11:10:51 +0100 Received: from SRV-FS-2.Demig.intra (nameserver.demig.intra [192.168.148.248]) by firewall.demig.intra (8.14.4/8.14.4) with ESMTP id r9UAARla065726 for ; Wed, 30 Oct 2013 11:10:27 +0100 (CET) (envelope-from nkoch@demig.de) Received: from [192.168.148.83] (192.168.148.83) by SRV-FS-2 (192.168.148.248) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 30 Oct 2013 11:10:22 +0100 Message-ID: <5270DB0E.1060704@demig.de> Date: Wed, 30 Oct 2013 11:10:22 +0100 From: Norbert Koch User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Subject: make_dev_alias and sub-directories Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 192.168.148.235 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 10:17:37 -0000 Hello. I have written a device driver which creates dev entries in a sub-directory of /dev, e.g.: /dev/mydev/mydev0a /dev/mydev/mydev0b /dev/mydev/mydev0c ... I want to alias mydev0a to mydev0. With make_dev_alias (pdev, "mydev/mydev0") I see an incorrect symlink: /dev/mydev/mydev0 -> mydev/mydev0a Calling make_dev_alias (pdev, "mydev0") works: /dev/mydev0 -> mydev/mydev0a But this is not what I want. Any way to get this /dev/mydev/mydev0 -> mydev0a ? In other words: Is the behaviour I see a bug or a feature? Thank you, Norbert Koch From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 30 13:21:43 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E85733E2 for ; Wed, 30 Oct 2013 13:21:43 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A55A12099 for ; Wed, 30 Oct 2013 13:21:43 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VbViD-0004eo-Ct for freebsd-hackers@freebsd.org; Wed, 30 Oct 2013 14:21:29 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Oct 2013 14:21:29 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Oct 2013 14:21:29 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Subject: Re: Automated submission of kernel panic reports Date: Wed, 30 Oct 2013 14:21:16 +0100 Lines: 48 Message-ID: References: <526F8EB3.1040205@freebsd.org> <527040F6.6080309@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NjpRuTqjUgEFLpjOqeWfO4swms0wdhe5X" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 In-Reply-To: <527040F6.6080309@freebsd.org> X-Enigmail-Version: 1.5.2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 13:21:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NjpRuTqjUgEFLpjOqeWfO4swms0wdhe5X Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 30/10/2013 00:12, Colin Percival wrote: > On 10/29/13 04:12, Ivan Voras wrote: >> On 29/10/2013 11:32, Colin Percival wrote: >>> If ${panicmail_autosubmit} is set to YES, this information is encrypt= ed >>> and submitted via email. The email which is sent looks like this:=20 >>> http://pastebin.com/AaCuxvDg >> >> I haven't tried it, but there's NetPGP (http://www.netpgp.com/) which = can >> be used to generate standard PGP-formatted messages instead of using a= >> custom format. What do you think about it? >=20 > If you need the full functionality of PGP, it looks great. But for thi= s > particular purpose I'd prefer to have 71 lines rather than 40,000 lines= =2E It's not that this thing needs PGP itself, but my concern was for not reinventing the data format wheel (for compatibility with other tools and for future reusability), even if the new wheel is 2352 times lighter than the existing one :) --NjpRuTqjUgEFLpjOqeWfO4swms0wdhe5X Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlJxB81fFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDYxNDE4MkQ3ODMwNDAwMDJFRUIzNDhFNUZE MDhENTA2M0RGRjFEMkMACgkQ/QjVBj3/HSzTFQCePZ+CqSQQp4XwbsQ3Yv4guBcs MtcAnjCTk0EtyEvJbHQQ/TihYUpV36/v =EZ/L -----END PGP SIGNATURE----- --NjpRuTqjUgEFLpjOqeWfO4swms0wdhe5X-- From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 30 18:34:22 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2CEC874C for ; Wed, 30 Oct 2013 18:34:22 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-vb0-x234.google.com (mail-vb0-x234.google.com [IPv6:2607:f8b0:400c:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E134829A2 for ; Wed, 30 Oct 2013 18:34:21 +0000 (UTC) Received: by mail-vb0-f52.google.com with SMTP id f13so1288643vbg.25 for ; Wed, 30 Oct 2013 11:34:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/IdJBigvxJaNgB1nXNeWGrHad4yIV4uxYHKBcyC1+XQ=; b=FvVPI2UAKRgygTXcmjLPpr/T7TsYfYrsYHm96zBAp6TylReP3M5pwPWRTPO4Ex9QaX W7QzchFuLV+GKjp/DjSaMMaR9s3dtbN09IfCsfGn0no1Ee6SfVaryiDEmlJfFR0h5vMh /+SwAQ8P/c/XMatHhXiXj03qgyhx3XbkIM/62MvNRhUUGH9YE9/+P163Fc3SGks9fsbn bomOVnP191JKCbx6pJvxLcmdLGsZA3W1rTh/SujKKzcf5yFgn69NdqRLkOew6Av1GvN3 fJlya5yRwWY0r5Q5Pe32KLofk4oOul0G95pAv5ynHEgenfj9S8aSstXOcK4rBwNi45DE Pjvg== MIME-Version: 1.0 X-Received: by 10.58.46.171 with SMTP id w11mr3980345vem.5.1383158060888; Wed, 30 Oct 2013 11:34:20 -0700 (PDT) Received: by 10.220.30.130 with HTTP; Wed, 30 Oct 2013 11:34:20 -0700 (PDT) Date: Wed, 30 Oct 2013 14:34:20 -0400 Message-ID: Subject: Two interesting things that broke in the package system while I wasn't looking. From: Zaphod Beeblebrox To: FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 18:34:22 -0000 The life-cycle of a machine often runs something like: - Machine gets installed/configured/put online for a purpose. - Someone pays attention for awihle. - It largely gets ignored - Then something breaks - Then someone has to pay attention Recently, I have encountered a hassle with a bunch of 7.2 machines that need upgrading. Two things, really, that are broken. I realize that 7.2 isn't supported... but these two things are errors that don't need to be errors --- it's just sloppy. The first is the code that recognizes a library is installed. I don't know where this is, but it recently changed s.t. it gives an error on 7.2 machines. Looks like sloppy shell code that doesn't work on 7.2's /bin/sh. The second is pkg itself. Not especially needed on 7.2, but one little check instead of just OS is FreeBSD for posix_fallocate(), is should be OS is FreeBSD _and_ OS_VERSION > something. I'm not sure what version posix_fallocate(0 appeared ... but that should be there. From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 31 00:29:58 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0AC49E7D for ; Thu, 31 Oct 2013 00:29:58 +0000 (UTC) (envelope-from dt71@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 97F802F70 for ; Thu, 31 Oct 2013 00:29:57 +0000 (UTC) Received: from [157.181.98.186] ([157.181.98.186]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LlqNY-1WAjqd3e88-00ZN8c for ; Thu, 31 Oct 2013 01:29:55 +0100 Message-ID: <5271A465.2030206@gmx.com> Date: Thu, 31 Oct 2013 01:29:25 +0100 From: dt71@gmx.com User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Firefox/24.0 SeaMonkey/2.21 MIME-Version: 1.0 To: Colin Percival , freebsd-hackers@freebsd.org Subject: Re: Automated submission of kernel panic reports References: <526F8EB3.1040205@freebsd.org> In-Reply-To: <526F8EB3.1040205@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:mN81ewHeaErx4AasDG/B/cnTYMq77Bg12NO+ne8qlrSXmBT05Pm U2jTucAFbIVtVv+x3gBo0vLkqKNOPLNu4eSRKXE/joId8P1g1FbIXehMEMBPIcf3Ppt5rBI 1A0cpyZ7FFJF17+W2PG8JIfaPoLw5K/Ix/+6EB65/ZyoTarqK33m5L5Q/kNcv17OGoMJdXN uEJdPKljdA0OBYpgMUU+w== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 00:29:58 -0000 Notes/advice/recommendations/proposals/questions/whatever: This smells of having a potential to make an admin accidentally transmit undesired information, as well as adding some attack surface. Without testing, I bet that a reguler user will be able to read the panicmail.N file (which will contain the textdump) -- the umask/permissions are not set up properly. I very much dislike the non-use of double quotes around variable expansions and things like that in the shell code. The return code of /usr/local/bin/pkesh should be handled. Place a comment to the location in the code where an admin could put an add-on script that can automatically modify the text to be submitted (both automatic and confirmed mode). What if the /var/crash/{info,vmcore}.last symlinks were used as a basis for selecting the last dump, instead of the current "$((`cat bounds` - 1))"/"$1" method? What's wrong with "our" /bin/sh? If a temporary file is used for kgdb commands anyway, would it not be cleaner to use ``-x ${tmpfile}'' instead of input-piping? How about: ${panicmail_sendto} could be "Full Name "? "# Remove temporary file" is a bit superfluous. Choose a consistent commenting style: either use periods/fullstops, or don't. I'd personally use ``>'' instead of ``>>'' first in panicmail_gather(). From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 31 03:36:40 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B255DD84; Thu, 31 Oct 2013 03:36:40 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 50E012B41; Thu, 31 Oct 2013 03:36:40 +0000 (UTC) Received: by mail-qe0-f46.google.com with SMTP id s14so1401417qeb.5 for ; Wed, 30 Oct 2013 20:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=pKpfJe6Cv6wc9DS+1G+bt3uxUhKsiAbQAyMvXrTRkKQ=; b=K9zXHCJ0/k7PXHfb6UmeraBCz6A7dqhT0+aqcMDV36JIv8oD//E5Ojb93xqMq5j5Hg 6dwpy0IYtUZKtZSzJ/H9oKSpElPOdZX6wUCdhVg9nBR73wGtz0E/qr3pDrE8m+2Qmvaw HrsFXx19Te/23HyYzxFj7gm+FnlCPs8rrS7GBrtbQGCIn9njwiUEWAnETAeHIsi/4NU0 AtAE2//wYNrHOVSh62PFyQfRlBXRFwt/UuY0fABaKqOEiaFjMFqsH4PewmTDKpFberMh /OuCZ4EGOCh6qlhY+DtqjrjWoalV5kNHFaxiWmkw/0StRmWhjlyENmtKQef7by1+PUzP EYog== X-Received: by 10.224.76.10 with SMTP id a10mr2228308qak.9.1383190599419; Wed, 30 Oct 2013 20:36:39 -0700 (PDT) Received: from raichu (24-212-218-13.cable.teksavvy.com. [24.212.218.13]) by mx.google.com with ESMTPSA id og1sm3084840qeb.3.2013.10.30.20.36.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Oct 2013 20:36:38 -0700 (PDT) Sender: Mark Johnston Date: Wed, 30 Oct 2013 23:36:36 -0400 From: Mark Johnston To: Andriy Gapon Subject: Re: sdt "sname" removal Message-ID: <20131031033636.GC9355@raichu> References: <5270246B.6070105@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5270246B.6070105@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@FreeBSD.org, dtrace@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 03:36:40 -0000 On Tue, Oct 29, 2013 at 11:11:07PM +0200, Andriy Gapon wrote: > > I never understood why FreeBSD SDT as opposed to upstream SDT requires the same > or almost the same probe name to be specified twice. This seems to be silly and > a little bit error-prone. > In other words, I do not see any reason not to re-use the original upstream > trick where double underscore in a providers name in the C code gets converted > to a single dash in a DTrace provider name. [*] > > So here is my take at that: > http://people.freebsd.org/~avg/sdt-sname-removal.diff > > An inline preview of the change: > -SDT_PROBE_DEFINE1(priv, kernel, priv_check, priv_ok, priv-ok, "int"); > -SDT_PROBE_DEFINE1(priv, kernel, priv_check, priv_err, priv-err, "int"); > +SDT_PROBE_DEFINE1(priv, kernel, priv_check, priv__ok, "int"); > +SDT_PROBE_DEFINE1(priv, kernel, priv_check, priv__err, "int"); > > It's possible that I missed some places where old style SDT_PROBE_DEFINE macros > are used or where an old probe name is used with SDT_PROBE_ARGTYPE or SDT_PROBE. A good way to test this is to compare the output of 'dtrace -lv' with and without your change. If nothing changes, I'd be pretty confident that the diff is correct. > > Please test, review, comment, etc. I don't think this diff will apply cleanly to head - I've made some changes that will cause conflicts, and the diff doesn't touch netinet/in_kdtrace.c or kern/subr_devstat.c. Could you also update the SDT(9) man page? Also the "strlcpy(name, ..." immediately before the loop you added to sdt.c becomes redundant. Thanks, -Mark From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 31 06:50:13 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DEB776BF; Thu, 31 Oct 2013 06:50:13 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id CF3D523B5; Thu, 31 Oct 2013 06:50:12 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id IAA14748; Thu, 31 Oct 2013 08:50:11 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Vbm54-000E0c-SJ; Thu, 31 Oct 2013 08:50:10 +0200 Message-ID: <5271FD6B.1040807@FreeBSD.org> Date: Thu, 31 Oct 2013 08:49:15 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Mark Johnston Subject: Re: sdt "sname" removal References: <5270246B.6070105@FreeBSD.org> <20131031033636.GC9355@raichu> In-Reply-To: <20131031033636.GC9355@raichu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, dtrace@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 06:50:13 -0000 on 31/10/2013 05:36 Mark Johnston said the following: > On Tue, Oct 29, 2013 at 11:11:07PM +0200, Andriy Gapon wrote: >> >> I never understood why FreeBSD SDT as opposed to upstream SDT requires the same >> or almost the same probe name to be specified twice. This seems to be silly and >> a little bit error-prone. >> In other words, I do not see any reason not to re-use the original upstream >> trick where double underscore in a providers name in the C code gets converted >> to a single dash in a DTrace provider name. [*] >> >> So here is my take at that: >> http://people.freebsd.org/~avg/sdt-sname-removal.diff >> >> An inline preview of the change: >> -SDT_PROBE_DEFINE1(priv, kernel, priv_check, priv_ok, priv-ok, "int"); >> -SDT_PROBE_DEFINE1(priv, kernel, priv_check, priv_err, priv-err, "int"); >> +SDT_PROBE_DEFINE1(priv, kernel, priv_check, priv__ok, "int"); >> +SDT_PROBE_DEFINE1(priv, kernel, priv_check, priv__err, "int"); >> >> It's possible that I missed some places where old style SDT_PROBE_DEFINE macros >> are used or where an old probe name is used with SDT_PROBE_ARGTYPE or SDT_PROBE. > > A good way to test this is to compare the output of 'dtrace -lv' with and > without your change. If nothing changes, I'd be pretty confident that > the diff is correct. Provided that my kernel has all of the SDT probes :-) >> >> Please test, review, comment, etc. > > I don't think this diff will apply cleanly to head - I've made some changes > that will cause conflicts, and the diff doesn't touch netinet/in_kdtrace.c > or kern/subr_devstat.c. Oh, yes, my head is from ~ 2 month ago. Need to update ASAP and will rebase the change then. > Could you also update the SDT(9) man page? Also > the "strlcpy(name, ..." immediately before the loop you added to sdt.c > becomes redundant. Good points. Will fix. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 31 07:09:23 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AB186C2B for ; Thu, 31 Oct 2013 07:09:23 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2737924D7 for ; Thu, 31 Oct 2013 07:09:22 +0000 (UTC) Received: from server.rulingia.com (c220-239-250-249.belrs5.nsw.optusnet.com.au [220.239.250.249]) by vps.rulingia.com (8.14.7/8.14.5) with ESMTP id r9V6tLb0032091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 31 Oct 2013 17:55:22 +1100 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.7/8.14.7) with ESMTP id r9V6tFXm014873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 31 Oct 2013 17:55:15 +1100 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.7/8.14.7/Submit) id r9V6tF94014872; Thu, 31 Oct 2013 17:55:15 +1100 (EST) (envelope-from peter) Date: Thu, 31 Oct 2013 17:55:15 +1100 From: Peter Jeremy To: Zaphod Beeblebrox Subject: Re: Two interesting things that broke in the package system while I wasn't looking. Message-ID: <20131031065515.GC14468@server.rulingia.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 07:09:23 -0000 --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2013-Oct-30 14:34:20 -0400, Zaphod Beeblebrox wrote: >Recently, I have encountered a hassle with a bunch of 7.2 machines that >need upgrading. Two things, really, that are broken. I realize that 7.2 >isn't supported... but these two things are errors that don't need to be >errors --- it's just sloppy. It's not "sloppy". "Not supported" means "not supported": Once a release isn't supported, developers don't need to worry about compatability with that release (and existing compatibility code is likely to be ripped out to reduce the maintenance effort). 7.2 has not been supported for more than 3 years and the last 7.x release went EoL 8 months ago. No-one is going to stop you running 7.x but you won't be able to use a current ports tree or current packages on it. --=20 Peter Jeremy --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iKYEARECAGYFAlJx/tNfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDBCRjc3QTcyNTg5NEVCRTY0RjREN0VFRUZF OEE0N0JGRjAwRkI4ODcACgkQ/opHv/APuIcQbACggjp+ZQZsZE3AZ3wNzr6griAI rG0An0NprtJrn5HKQGhsRs4chPiq/jEe =WUrZ -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND-- From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 31 09:10:11 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 44BAE70F; Thu, 31 Oct 2013 09:10:11 +0000 (UTC) (envelope-from satan@ukr.net) Received: from hell.ukr.net (hell.ukr.net [212.42.67.68]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F2EE82BA2; Thu, 31 Oct 2013 09:10:10 +0000 (UTC) Received: from satan by hell.ukr.net with local ID 1VboGX-0004CO-1f ; Thu, 31 Oct 2013 11:10:09 +0200 Date: Thu, 31 Oct 2013 11:10:09 +0200 From: Vitalij Satanivskij To: Andriy Gapon Subject: Re: FreeBSD 10.0-BETA1 #8 r256765M spend too much time in locks Message-ID: <20131031091008.GA15005@hell.ukr.net> References: <20131024074826.GA50853@hell.ukr.net> <20131024075023.GA52443@hell.ukr.net> <20131024115519.GA72359@hell.ukr.net> <20131024165218.GA82686@hell.ukr.net> <526A11B2.6090008@FreeBSD.org> <20131025072343.GA31310@hell.ukr.net> <526A4306.2060500@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <526A4306.2060500@FreeBSD.org> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: Vitalij Satanivskij , freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 09:10:11 -0000 Andriy Gapon wrote: AG> on 25/10/2013 10:23 Vitalij Satanivskij said the following: AG> > AG> > AG> > http://quad.org.ua/profiling.tgz AG> > AG> > results of both methods AG> > AG> > but for pmcstat to few buffers configured by default so not all statistics in summary ^( AG> AG> From these profiling results alone I do not see pathologies. AG> It looks like you have a lot of I/O going on[*]. AG> My guess is that the I/O requests are sufficiently small and contiguous, so ZFS AG> performs a lot for I/O aggregation. For that it allocates and then frees a lot AG> of temporary buffers. AG> And it seems that that's where the locks are greatly contended and CPU is AG> burned. Specifically in KVA allocation in vmem_xalloc/vmem_xfree. AG> AG> You can try at least two approaches. AG> AG> 1. Disable I/O aggregation. AG> See the following knobs: AG> vfs.zfs.vdev.aggregation_limit: I/O requests are aggregated up to this size AG> vfs.zfs.vdev.read_gap_limit: Acceptable gap between two reads being aggregated AG> vfs.zfs.vdev.write_gap_limit: Acceptable gap between two writes being aggregated AG> AG> 2. Try to improve buffer allocation performance by using uma(9) for that. AG> vfs.zfs.zio.use_uma=1 AG> This is a boot time tunable. AG> AG> Footnotes: AG> [*] But perhaps there is some pathology that causes all that I/O to happen. I AG> can't tell that from the profiling data. So this could be another thing to try AG> to check. AG> Ok some new information Trying to Disable I/O aggregation by setting sysctl first to smaller values then to "0" cause to very high load Setting vfs.zfs.zio_use_uma=1 cause system panic and reboot at starup on freebsd 10 beta1 and beta2 (no debug in kernel) on freebsd 11 current r257395 on GENERIC kernel there is no panic but I heve no idea how much time will take setup and data merge on thouse system. From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 31 19:27:19 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 98614A12; Thu, 31 Oct 2013 19:27:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 22F212B08; Thu, 31 Oct 2013 19:27:19 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1236FB9C3; Thu, 31 Oct 2013 15:27:18 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: make_dev_alias and sub-directories Date: Thu, 31 Oct 2013 14:44:33 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <5270DB0E.1060704@demig.de> In-Reply-To: <5270DB0E.1060704@demig.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201310311444.33364.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 31 Oct 2013 15:27:18 -0400 (EDT) Cc: Norbert Koch , kib@freebsd.org, phk@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 19:27:19 -0000 On Wednesday, October 30, 2013 6:10:22 am Norbert Koch wrote: > Hello. > > I have written a device driver which > creates dev entries in a sub-directory of /dev, e.g.: > /dev/mydev/mydev0a > /dev/mydev/mydev0b > /dev/mydev/mydev0c ... > > I want to alias mydev0a to mydev0. > > With make_dev_alias (pdev, "mydev/mydev0") I see an incorrect symlink: > /dev/mydev/mydev0 -> mydev/mydev0a > > Calling make_dev_alias (pdev, "mydev0") works: > /dev/mydev0 -> mydev/mydev0a > But this is not what I want. > > Any way to get this > /dev/mydev/mydev0 -> mydev0a ? > > In other words: Is the behaviour I see a bug or a feature? I think it is an oversight, but I'm not sure which way it should work. Probably we should parse the passed in alias name and add '../' prefixes to the 'pdev' name to generate the symlink contents so that you get: /dev/mydev/mydev0 -> ../mydev/mydev0a This would also let you do something like make_dev_alias(null, "foo/null2") to create: /dev/foo/null2 -> ../null -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 1 09:35:04 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 97D6C9B4 for ; Fri, 1 Nov 2013 09:35:04 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3442A2C0C for ; Fri, 1 Nov 2013 09:35:04 +0000 (UTC) Received: by mail-ee0-f41.google.com with SMTP id e53so1895176eek.14 for ; Fri, 01 Nov 2013 02:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:subject:date:content-type :content-transfer-encoding; bh=L+u4pTpBG7mSMz7o2tVufSYcXg0WbFpnsxdl5iwgaAg=; b=jqK1s58cLqGc7mVPmBYU7p+/PnWR8FL6b2KedYUk9k6y2TI7XX6KGC1ea+YwzqrFUv Wri9ACbTkYMNmT9XTUbDkhacazS5KEBKTn1+cTa4Jglw79x05MQG0V/3YSAieJhijhj+ oQ//72tfvGBopZvZXHyMjU9blYudt8cmezWW2EyxsMM6lrStdNEUS0ZaG9n2QdXKrqna 8TNPjh9tX8D/BF/vGguKh6rGO64jRpcsVJ/fYOmybvsdr82jkuqn8z4umGyCT+Dcs6UE CqUMXQOh41jrkq64u0LwCFuInmihtO7dovvk+EznLWexHHJYXE/6OSqgqxrz3wwylHTU SbgQ== X-Received: by 10.14.174.131 with SMTP id x3mr2008010eel.25.1383298501721; Fri, 01 Nov 2013 02:35:01 -0700 (PDT) Received: from DOMYPC ([82.193.208.225]) by mx.google.com with ESMTPSA id b42sm5428412eem.9.2013.11.01.02.34.59 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 01 Nov 2013 02:35:00 -0700 (PDT) Message-ID: <20131101.093502.682.1@DOMY-PC> From: rank1seeker@gmail.com To: hackers@freebsd.org Subject: RELEASE 9.2 build Date: Fri, 01 Nov 2013 10:35:02 +0100 Content-Type: text/plain; charset="Windows-1250" Content-Transfer-Encoding: quoted-printable X-Mailer: POP Peeper (3.8.1.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 09:35:04 -0000 So, upon shift from 9.1 to 9.2 at installworld part, I've received ONLY '1 = error', as I use my script, which separates STDOUT to /dev/null and = STDERR to console.=0D=0AI had to manually navigate to /usr/src and do a = 'installworld' JUST to see error msg. ('auditdistd' user had to be = added)=0D=0A=0D=0AI talk about this issue from 8.*!=0D=0ACompilation of = /usr/src (tested 9.2), STILL outputs EVERYTHING to STDOUT!=0D=0AWhen will = it finally start to separate errors to = STDERR?!=0D=0A=0D=0A=0D=0A=0D=0ANext problem is tied to ports, which have = kernel modules.=0D=0AAfter above minor shift, I had ntfs fuse related = panics, upon umount of ntfs, which were fixed by rebuilding = 'sysutils/fusefs-kmod'=0D=0A=0D=0ASo I added = 'PORTS_MODULES=3Dsysutils/fusefs-kmod' into '/etc/make.conf' and got this = upon kernel rebuild=0D=0A# /usr/bin/make -j4 buildkernel = KERNCONF=3DSERVER=0D=0A-----------------------=0D=0AStop in = /usr/obj/usr/src/sys/SERVER/usr/ports/sysutils/fusefs-kmod/work/fuse4bsd-498acaef33b0.=0D=0A=3D=3D=3D> = Compilation failed unexpectedly.=0D=0ATry to set MAKE_JOBS_UNSAFE=3Dyes = and rebuild before reporting the failure to=0D=0Athe maintainer.=0D=0A*** = [do-build] Error code 1=0D=0A=0D=0AStop in = /usr/ports/sysutils/fusefs-kmod.=0D=0A*** [build] Error code = 1=0D=0A=0D=0AStop in /usr/ports/sysutils/fusefs-kmod.=0D=0A*** [all] = Error code 1=0D=0A1 error=0D=0A*** [buildkernel] Error code 2=0D=0A1 = error=0D=0A*** [buildkernel] Error code 2=0D=0A1 = error=0D=0A-----------------------=0D=0A=0D=0A=0D=0AAs advised, I added = 'MAKE_JOBS_UNSAFE=3Dyes', without jobs:=0D=0A=0D=0A# make buildkernel = KERNCONF=3DSERVER = MAKE_JOBS_UNSAFE=3Dyes=0D=0A-----------------------=0D=0Afuse_vfsops.c: = In function 'fuse_mount':=0D=0Afuse_vfsops.c:339: warning: passing = argument 3 of 'vfs_flagopt' from incompatible pointer = type=0D=0Afuse_vfsops.c:339: warning: passing argument 3 of 'vfs_flagopt' = from incompatible pointer type=0D=0Afuse_vfsops.c:340: warning: passing = argument 3 of 'vfs_flagopt' from incompatible pointer = type=0D=0Afuse_vfsops.c:340: warning: passing argument 3 of 'vfs_flagopt' = from incompatible pointer type=0D=0Afuse_vfsops.c:341: warning: passing = argument 3 of 'vfs_flagopt' from incompatible pointer = type=0D=0Afuse_vfsops.c:341: warning: passing argument 3 of 'vfs_flagopt' = from incompatible pointer type=0D=0Afuse_vfsops.c:342: warning: passing = argument 3 of 'vfs_flagopt' from incompatible pointer = type=0D=0Afuse_vfsops.c:342: warning: passing argument 3 of 'vfs_flagopt' = from incompatible pointer type=0D=0Afuse_vfsops.c:343: warning: passing = argument 3 of 'vfs_flagopt' from incompatible pointer = type=0D=0Afuse_vfsops.c:343: warning: passing argument 3 of 'vfs_flagopt' = from incompatible pointer type=0D=0Afuse_vfsops.c:345: warning: passing = argument 3 of 'vfs_flagopt' from incompatible pointer = type=0D=0Afuse_vfsops.c:345: warning: passing argument 3 of 'vfs_flagopt' = from incompatible pointer type=0D=0A*** [fuse_vfsops.o] Error code = 1=0D=0A=0D=0AStop in = /usr/obj/usr/src/sys/SERVER/usr/ports/sysutils/fusefs-kmod/work/fuse4bsd-498acaef33b0/fuse_module.=0D=0A*** = [all] Error code 1=0D=0A=0D=0AStop in = /usr/obj/usr/src/sys/SERVER/usr/ports/sysutils/fusefs-kmod/work/fuse4bsd-498acaef33b0.=0D=0A*** = [do-build] Error code 1=0D=0A=0D=0AStop in = /usr/ports/sysutils/fusefs-kmod.=0D=0A*** [build] Error code = 1=0D=0A=0D=0AStop in /usr/ports/sysutils/fusefs-kmod.=0D=0A*** [all] = Error code 1=0D=0A=0D=0AStop in /usr/obj/usr/src/sys/SERVER.=0D=0A*** = [buildkernel] Error code 1=0D=0A=0D=0AStop in /usr/src.=0D=0A*** = [buildkernel] Error code 1=0D=0A=0D=0AStop in = /usr/src.=0D=0A-----------------------=0D=0A=0D=0A=0D=0ASo what = now?=0D=0A=0D=0A=0D=0A=0D=0ADomagoj Smol=E8i=E6 From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 1 10:32:11 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 753C04CB for ; Fri, 1 Nov 2013 10:32:11 +0000 (UTC) (envelope-from symbolics@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EE2C62FD6 for ; Fri, 1 Nov 2013 10:32:10 +0000 (UTC) Received: from lemon ([80.7.17.14]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MUDXS-1VBLUp3nZy-00R13Y for ; Fri, 01 Nov 2013 11:32:02 +0100 Received: by lemon (Postfix, from userid 1001) id 4647FEB372; Fri, 1 Nov 2013 10:31:58 +0000 (GMT) Date: Fri, 1 Nov 2013 10:31:58 +0000 From: symbolics@gmx.com To: hackers@freebsd.org Subject: GEOM mentor request Message-ID: <20131101103158.GA35397@lemon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Provags-ID: V03:K0:973fMirGNLIq8cR8nfTacXwjIWVhbG6jOcN0xJ6fpolhg+/PGnD a+zEEs0f/GLt4uGuAGkv8WNVPiM0W8MLqWNJasx5mKMabdw9QUPXl81DNw3qbQM6ycHmHfM CLddAQXQd56zLBS5c9EBhIYfxsXVxc2LKvplh0m57qMqEhRPVda43j5CJvW8xk80LaeNVAY YygrFIcFV4xFNYO7QLGQw== Cc: geom@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 10:32:11 -0000 Hi hackers, I have been studying the GEOM documentation and source recently. Is anyone actively maintaining this subsystem at the moment? I would like to give it some attention. A few example things I'd like to work on (in no particular order): + Developer manual pages. Rewrite for clarity and add cover some of the areas not discussed yet. + Add a tutorial on writing GEOM classes, either in the dev handbook or within the manual pages. + Add missing manual pages so every class has a complete set. + Implement various helper methods to reduce code duplication across GEOM classes. There seems to be quite a bit of C&P currently. + Attack GEOM PR list. Lots of PRs have not progressed in a long time. + Implement a method for controlling tasting; there are some cases where this would be helpful. Bhyve is one, apparently iSCSI might be another. + I have a patch that adds connect/disconnect verbs to the DISK class. Disconnect sets a flag that disables tasting on the geom and withers all but the GEOM's DEV provider. This lets me use a raw disc with virtio-blk in Bhyve (with a few other problems). + Add regression tests for various classes, especially the ones that do not support writing metadata and are therefore more difficult to test, LINUX_LVM, for instance. + Try and resolve the various XXX comments sitting in the code. + Implement new things. Some ideas I have had: + GEOM "ERASE" - Rewrite deletes into random writes. + GEOM "PLUG" - Persistent version of the connect/disconnect verbs where the flag sits in the class metadata. This might be a cleaner approach, rather than adding the verbs to all the existing providers. + GEOM "TAP" - Allow userspace processes to hook into the GEOM API. Intended for debugging and development. + GEOM "WCACHE" - Allow you to use small, fast provider as a buffer for a larger, slower provider. + GEOM DTrace provider. Provide GEOM specific probes to complement the IO provider. + Probably other bits I can't remember right now. I need someone more experienced in kernel programming who can review my ideas and work and guide my patches into the tree. Given that lots of the GEOM PRs don't seem to be moving, I don't really want to do the work for it to rot in GNATS. Any volunteers please get in touch. Thanks! --sym From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 1 12:47:25 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3D73D95C for ; Fri, 1 Nov 2013 12:47:25 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (mx.nsu.ru [84.237.50.39]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D61CC2941 for ; Fri, 1 Nov 2013 12:47:24 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.69) (envelope-from ) id 1VcE83-0004DC-Ri for hackers@freebsd.org; Fri, 01 Nov 2013 19:47:12 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id rA1CkprX076718 for ; Fri, 1 Nov 2013 19:47:01 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id rA1CkkE4076668 for hackers@freebsd.org; Fri, 1 Nov 2013 19:46:46 +0700 (NOVT) (envelope-from danfe) Date: Fri, 1 Nov 2013 19:46:46 +0700 From: Alexey Dokuchaev To: hackers@freebsd.org Subject: SSE2 intrinsics: gcc46 vs. clang contradiction Message-ID: <20131101124645.GA73456@regency.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Fri, 01 Nov 2013 13:05:10 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 12:47:25 -0000 Hi there, I've recently encountered a piece of code that uses some SSE2 intrinsics and builds with gcc46, but not clang: clang can't find _mm_movpi64_epi64(), while gcc46 defines it in its lib/gcc46/gcc/.../4.6.3/include/emmintrin.h: extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__, __artificial__)) _mm_movpi64_epi64 (__m64 __A) { return _mm_set_epi64 ((__m64)0LL, __A); } extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__, __artificial__)) _mm_set_epi64x (long long __q1, long long __q0) { return __extension__ (__m128i)(__v2di){ __q0, __q1 }; } Now, Clang in /usr/include/clang/3.3/emmintrin.h defines similar function, but without the `e', _mm_movpi64_pi64(): static __inline__ __m128i __attribute__((__always_inline__, __nodebug__)) _mm_movpi64_pi64(__m64 __a) { return (__m128i){ (long long)__a, 0 }; } So what's going on here? Who is right? What adds to confusion, in their manual [1] Intel spells them differently themselves: first, in the table, it says: _mm_movpi64_epi64 Move MOVDQ2Q ^^^^^ Then later, when they describe what it does, it says: __m128i _mm_movpi64_pi64(__m64 a) ^^^^ Moves the 64 bits of a to the lower 64 bits of the result, zeroing the upper bits. Or I'm just being stupid and confusing two different functions? ./danfe [1] http://software.intel.com/sites/products/documentation/doclib/iss/2013/compiler/cpp-lin/GUID-AFA947A7-8490-443B-9946-C7B16C8E6244.htm From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 1 16:07:36 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 931AC67D; Fri, 1 Nov 2013 16:07:36 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6E31326B2; Fri, 1 Nov 2013 16:07:36 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id rA1G7ZDG072205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Nov 2013 09:07:35 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id rA1G7YtT072204; Fri, 1 Nov 2013 09:07:34 -0700 (PDT) (envelope-from jmg) Date: Fri, 1 Nov 2013 09:07:34 -0700 From: John-Mark Gurney To: symbolics@gmx.com Subject: Re: GEOM mentor request Message-ID: <20131101160734.GL58155@funkthat.com> Mail-Followup-To: symbolics@gmx.com, hackers@freebsd.org, geom@freebsd.org References: <20131101103158.GA35397@lemon> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131101103158.GA35397@lemon> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 01 Nov 2013 09:07:35 -0700 (PDT) Cc: geom@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 16:07:36 -0000 symbolics@gmx.com wrote this message on Fri, Nov 01, 2013 at 10:31 +0000: [...] > I need someone more experienced in kernel programming who can review my > ideas and work and guide my patches into the tree. Given that lots of > the GEOM PRs don't seem to be moving, I don't really want to do the work > for it to rot in GNATS. > > Any volunteers please get in touch. If a better candiate doesn't come forward, I'm willing to work w/ you on these items. A number of the items you listed I've been wanting to do myself or I have been anoyed by them and wanted to fix. Though I'm volunteering to help, don't forget that most patches should still be reviewed publicly, so you'll want to keep working on the -geom mailing list. Thanks for your interest and work. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 1 15:43:52 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EBB9E9A2 for ; Fri, 1 Nov 2013 15:43:52 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (mx.nsu.ru [84.237.50.39]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 923C82562 for ; Fri, 1 Nov 2013 15:43:52 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.69) (envelope-from ) id 1VcGsv-00077d-ID for hackers@freebsd.org; Fri, 01 Nov 2013 22:43:46 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id rA1FhQMs014968 for ; Fri, 1 Nov 2013 22:43:36 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id rA1FhLOt014929 for hackers@freebsd.org; Fri, 1 Nov 2013 22:43:21 +0700 (NOVT) (envelope-from danfe) Date: Fri, 1 Nov 2013 22:43:20 +0700 From: Alexey Dokuchaev To: hackers@freebsd.org Subject: Re: SSE2 intrinsics: gcc46 vs. clang contradiction Message-ID: <20131101154320.GA11359@regency.nsu.ru> References: <20131101124645.GA73456@regency.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131101124645.GA73456@regency.nsu.ru> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Fri, 01 Nov 2013 16:09:31 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 15:43:53 -0000 On Fri, Nov 01, 2013 at 07:46:45PM +0700, Alexey Dokuchaev wrote: > What adds to confusion, in their manual [1] Intel spells them differently > themselves: first, in the table, it says: > > _mm_movpi64_epi64 Move MOVDQ2Q > ^^^^^ > > Then later, when they describe what it does, it says: > > __m128i _mm_movpi64_pi64(__m64 a) > ^^^^ > Moves the 64 bits of a to the lower 64 bits of the result, zeroing the > upper bits. Microsoft (http://msdn.microsoft.com/en-us/library/has3d153(v=vs.90).aspx) defines these two: _mm_movepi64_pi64 MOVDQ2Q Move _mm_movpi64_epi64 MOVQ2DQ Move That is: __m64 _mm_movepi64_pi64 (__m128i a); MOVDQ2Q r0 := a0 ; __m128i _mm_movpi64_epi64 (__m64 a); MOVDQ2Q r0 := a0 ; r1 := 0X0 ; Cf. Intel's: _mm_movepi64_pi64 Move MOVDQ2Q _mm_movpi64_epi64 Move MOVDQ2Q __m64 _mm_movepi64_pi64(__m128i a) Returns the lower 64 bits of a as an __m64 type: R0 := a0 __m128i _mm_movpi64_pi64(__m64 a) Moves the 64 bits of a to the lower 64 bits of the result, zeroing the upper bits: R0 := a0, R1 = 0X0 Assuming that both documents correctly assign instructions to function names (bonus clue: it also makes them symmetrical), then _mm_movpi64_pi64 is indeed a typo and Clang's header is wrong, while GCC's is correct: it should read _mm_movpi64_epi64(), not _mm_movpi64_pi64(). ./danfe From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 1 18:27:24 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5D892C84 for ; Fri, 1 Nov 2013 18:27:24 +0000 (UTC) (envelope-from symbolics@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E5B942F15 for ; Fri, 1 Nov 2013 18:27:23 +0000 (UTC) Received: from lemon ([80.7.17.14]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MXmpv-1V7fmO2gel-00Wmtb for ; Fri, 01 Nov 2013 19:27:15 +0100 Received: by lemon (Postfix, from userid 1001) id 1E0DBEB372; Fri, 1 Nov 2013 18:27:15 +0000 (GMT) Date: Fri, 1 Nov 2013 18:27:15 +0000 From: symbolics@gmx.com To: freebsd-hackers@freebsd.org Subject: Re: GEOM mentor request Message-ID: <20131101182715.GA1762@lemon> References: <20131101103158.GA35397@lemon> <20131101160734.GL58155@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131101160734.GL58155@funkthat.com> X-Provags-ID: V03:K0:56NKOwx3FbF/DG+smPsC0oRqF0ambzCrd+HaMi7QdeGDJTKJrdF UwgAlY/7BiKmwG//kzJT57ZFNaPgoILgUW+wwhrBQwuzJs8/pkQnaIhkO4VY2h5xWYhJL2V j2vP3QKVCfZ0ReB7fBqOc560mMoGSQc1w6DqBJ1w3I5L/nmAQXdR4bou+8KLpaa4LxvhJO4 YXmjkrKnpz8JcQyBYuwkg== Cc: geom@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 18:27:24 -0000 On Fri, Nov 01, 2013 at 09:07:34AM -0700, John-Mark Gurney wrote: > symbolics@gmx.com wrote this message on Fri, Nov 01, 2013 at 10:31 +0000: > > [...] > > > I need someone more experienced in kernel programming who can review my > > ideas and work and guide my patches into the tree. Given that lots of > > the GEOM PRs don't seem to be moving, I don't really want to do the work > > for it to rot in GNATS. > > > > Any volunteers please get in touch. > > If a better candiate doesn't come forward, I'm willing to work w/ you > on these items. A number of the items you listed I've been wanting to > do myself or I have been anoyed by them and wanted to fix. > > Though I'm volunteering to help, don't forget that most patches should > still be reviewed publicly, so you'll want to keep working on the -geom > mailing list. > > Thanks for your interest and work. > Great. I'll start work on a plan then and submit the bits to geom@. Thanks a lot! --sym From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 1 18:31:07 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 36CFCF0E for ; Fri, 1 Nov 2013 18:31:07 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C71F42F75 for ; Fri, 1 Nov 2013 18:31:06 +0000 (UTC) Received: by mail-ee0-f48.google.com with SMTP id d49so2144243eek.21 for ; Fri, 01 Nov 2013 11:31:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=NoaoRnX8gfYJJS/lrufLZe43gYFKX9sQd47lMsoO9O0=; b=VsWMXiiqbouw9V11AkklyufbStKcOFSw0hOUhg4dL6D0JpxoSxFNVrYy5lBSe4A8Te Ay1q2CExVoa5lTTbET3nLngP7EhkGDF7e6ewcDbWWMB1XDy4kIQi2+PAC65z9bMiffQN 5/jo/QOioJnnOAbsPuIMagadFBgBc3R6WrLlmvn2wr7eLEWMZMqquREFbtT/943kebWt sfcpK0lJIfPs8OaLExQ3Jbsjr91gz4py/9HItHufAXWboHQ5wvLdwggAaB/EvN+j4ZoK LIYRI6gHaWAVPm1bR4maaJ3Fpw66ooDZjUSJ2t1ytDu5uVZ1zh0rvM5JC3KjabJetTV1 f1SA== MIME-Version: 1.0 X-Received: by 10.14.173.198 with SMTP id v46mr443110eel.132.1383330665144; Fri, 01 Nov 2013 11:31:05 -0700 (PDT) Received: by 10.223.152.72 with HTTP; Fri, 1 Nov 2013 11:31:05 -0700 (PDT) Date: Fri, 1 Nov 2013 11:31:05 -0700 Message-ID: Subject: regd. thread ucred update in kern_accessat() From: Vijay Singh To: hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 18:31:07 -0000 Hi hackers. In kern_accessat() [I'm looking at 8.2 code], for the case where flags doesn't have AT_EACCESS set, we make a local copy of the thread ucred. This is then passed in to vn_access(). My question is why we update td->td_ucred with this temporary ucred? tmpcred = crdup(cred); tmpcred->cr_uid = cred->cr_ruid; tmpcred->cr_groups[0] = cred->cr_rgid; ==> td->td_ucred = tmpcred; At this point p->p_ucred != td->td_ucred. Couldn't this cause issues? Wouldn't it just suffice to use the tempcred as an argument to vn_access() and leave the thread's ucred intact? -vijay From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 1 19:23:13 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EDB6236C; Fri, 1 Nov 2013 19:23:13 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A0B2E22BE; Fri, 1 Nov 2013 19:23:13 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id rA1JNCqJ023754; Fri, 1 Nov 2013 13:23:12 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id rA1JNCpQ023751; Fri, 1 Nov 2013 13:23:12 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Fri, 1 Nov 2013 13:23:12 -0600 (MDT) From: Warren Block To: symbolics@gmx.com Subject: Re: GEOM mentor request In-Reply-To: <20131101103158.GA35397@lemon> Message-ID: References: <20131101103158.GA35397@lemon> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Fri, 01 Nov 2013 13:23:12 -0600 (MDT) Cc: geom@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 19:23:14 -0000 On Fri, 1 Nov 2013, symbolics@gmx.com wrote: > + Implement new things. Some ideas I have had: > + GEOM "ERASE" - Rewrite deletes into random writes. > + GEOM "PLUG" - Persistent version of the connect/disconnect verbs > where the flag sits in the class metadata. This might be a cleaner > approach, rather than adding the verbs to all the existing > providers. > + GEOM "TAP" - Allow userspace processes to hook into the GEOM > API. Intended for debugging and development. > + GEOM "WCACHE" - Allow you to use small, fast provider as a buffer > for a larger, slower provider. > + GEOM DTrace provider. Provide GEOM specific probes to complement > the IO provider. > + Probably other bits I can't remember right now. How about an explicit geom retaste command? "true > /dev/ada0" is misleading to the reader. Also, a RAM-cached version of gmirror that would report writes finished as soon as the faster drive finishes. Kind of the opposite of the WCACHE above. This would permit creating mirrors of an SSD and hard drive without performance loss, at least up until available write buffer space runs out. This one may not be so easy. From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 1 19:32:59 2013 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 000206B2; Fri, 1 Nov 2013 19:32:58 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C8934234A; Fri, 1 Nov 2013 19:32:58 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VcKSn-000Ka2-8x; Fri, 01 Nov 2013 19:32:57 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id rA1JWsBM057315; Fri, 1 Nov 2013 13:32:54 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19nIPHugGz368Ua80q8ayZS Subject: Re: GEOM mentor request From: Ian Lepore To: Warren Block In-Reply-To: References: <20131101103158.GA35397@lemon> Content-Type: text/plain; charset="us-ascii" Date: Fri, 01 Nov 2013 13:32:54 -0600 Message-ID: <1383334374.31172.95.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: geom@FreeBSD.org, hackers@FreeBSD.org, symbolics@gmx.com X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 19:32:59 -0000 On Fri, 2013-11-01 at 13:23 -0600, Warren Block wrote: > How about an explicit geom retaste command? "true > /dev/ada0" is > misleading to the reader. +1. That's just a good idea. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 1 19:36:01 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 20212840; Fri, 1 Nov 2013 19:36:01 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D6919237D; Fri, 1 Nov 2013 19:36:00 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id rA1JZr3A075368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Nov 2013 12:35:54 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id rA1JZrcE075367; Fri, 1 Nov 2013 12:35:53 -0700 (PDT) (envelope-from jmg) Date: Fri, 1 Nov 2013 12:35:53 -0700 From: John-Mark Gurney To: Warren Block Subject: Re: GEOM mentor request Message-ID: <20131101193553.GE73243@funkthat.com> Mail-Followup-To: Warren Block , symbolics@gmx.com, geom@freebsd.org, hackers@freebsd.org References: <20131101103158.GA35397@lemon> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 01 Nov 2013 12:35:54 -0700 (PDT) Cc: geom@freebsd.org, hackers@freebsd.org, symbolics@gmx.com X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 19:36:01 -0000 Warren Block wrote this message on Fri, Nov 01, 2013 at 13:23 -0600: > On Fri, 1 Nov 2013, symbolics@gmx.com wrote: > > > + Implement new things. Some ideas I have had: > > + GEOM "ERASE" - Rewrite deletes into random writes. > > + GEOM "PLUG" - Persistent version of the connect/disconnect verbs > > where the flag sits in the class metadata. This might be a cleaner > > approach, rather than adding the verbs to all the existing > > providers. > > + GEOM "TAP" - Allow userspace processes to hook into the GEOM > > API. Intended for debugging and development. > > + GEOM "WCACHE" - Allow you to use small, fast provider as a buffer > > for a larger, slower provider. > > + GEOM DTrace provider. Provide GEOM specific probes to complement > > the IO provider. > > + Probably other bits I can't remember right now. > > How about an explicit geom retaste command? "true > /dev/ada0" is > misleading to the reader. > > Also, a RAM-cached version of gmirror that would report writes finished > as soon as the faster drive finishes. Kind of the opposite of the > WCACHE above. This would permit creating mirrors of an SSD and hard > drive without performance loss, at least up until available write > buffer space runs out. This one may not be so easy. If you did that, you'd want to do something like set the SSD to prefer, and only complete on that drive.. That way if there is ever a crash, you mirror the second disk from the faster first... Though this still has the possibility to leave your fs is a inconsistent state as once the write for the faster drive completes, another write could come in and complete on the second drive before the first IO completes breaking the assumptions that UFS+S and ZFS about how/when IO gets committed to the disk... Also, depending upon the write load, it could be the HD is faster than the SSD if there was a large enough volume of writes... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 1 20:27:37 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C1DDC918 for ; Fri, 1 Nov 2013 20:27:37 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5D8CC265E for ; Fri, 1 Nov 2013 20:27:37 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id ey11so1600444wid.1 for ; Fri, 01 Nov 2013 13:27:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=GgcrQVBYIJvq2NNOPcEf30V8b9DTBgQ70jeSfUcVQ+Y=; b=NGW4tP556roz07vkkz6HkcOzHquh3jrTSRNJQRAYkVMuDt8r9Z0uPokL75piwq/dFw UjV7JF9AVPnst7x0l8QZzozJkc8x4FXwOIt/Xg1tb29ICJJirX64ZOjYwkP9EOkbhG+p NwTOghQMtpw6ITOEV/hxb1TAl4OI/XMTrAiA0Xq3xOiQGMevDXS5oFK9PSPRTi683Hou 8g72XkoAISmm++CCRN0c6IRPBhs8Hu6SDATo6wJUiTIgsc8Ov34Dj4PJARxwfFsNnlcn HZYmkSFFRRg8S/KHGsjwmTvJEVyrOI80IZCSROjKs5SF7BXmTf71CuX+adeHih2md8sS acmw== X-Received: by 10.180.160.240 with SMTP id xn16mr3710254wib.62.1383337655044; Fri, 01 Nov 2013 13:27:35 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id b7sm10760494wiz.8.2013.11.01.13.27.33 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 01 Nov 2013 13:27:34 -0700 (PDT) Date: Fri, 1 Nov 2013 21:27:29 +0100 From: Mateusz Guzik To: Vijay Singh Subject: Re: regd. thread ucred update in kern_accessat() Message-ID: <20131101202729.GA19342@dft-labs.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 20:27:37 -0000 On Fri, Nov 01, 2013 at 11:31:05AM -0700, Vijay Singh wrote: > Hi hackers. In kern_accessat() [I'm looking at 8.2 code], for the case > where flags doesn't have AT_EACCESS set, we make a local copy of the thread > ucred. This is then passed in to vn_access(). My question is why we update > td->td_ucred with this temporary ucred? > /me takes nitpicky hat on For starters you should have checked newer tree - maybe this code would be gone and you would get an answer from respective commit. /me takes the hat off > tmpcred = crdup(cred); > tmpcred->cr_uid = cred->cr_ruid; > tmpcred->cr_groups[0] = cred->cr_rgid; > ==> td->td_ucred = tmpcred; > > At this point p->p_ucred != td->td_ucred. Couldn't this cause issues? Can you elaborate what you have in mind? This is fine. In fact, when you do setuid() thread credentials are updated only on syscall boundary. In worst case syscall that is being performed at the moment is using old credentials which is ok - whatever you wanted to do with it you can do before calling setuid() :) Other case would be when you drop some privs and suddenly something is allowed to ptrace you. Even if that was the case, already executing syscall cannot be altered and credentials are changed for another one. > Wouldn't it just suffice to use the tempcred as an argument to vn_access() > and leave the thread's ucred intact? > Before vn_access you can find namei call and it uses thread credentials. Specifically ndp->ni_cnd.cn_thread->td_ucred, as populated by NDINIT_ATRIGHTS. Maybe creating another macro which allows one to supply credentials would be ok, but one would have to go first through the code from namei and vn_access down the stack and check for td_ucred users (this should be fine, but just in case). -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 1 21:45:06 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BAAEA5C3 for ; Fri, 1 Nov 2013 21:45:06 +0000 (UTC) (envelope-from cbergstrom@pathscale.com) Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 917632A42 for ; Fri, 1 Nov 2013 21:45:06 +0000 (UTC) Received: by mail-pd0-f178.google.com with SMTP id x10so4414373pdj.9 for ; Fri, 01 Nov 2013 14:45:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=P/ytO3ogZ97LwpPCw0waJ326MBLKLuWN+tdcS9mB2n8=; b=WnHyDIUlgRP5YTjWYFQoeV6//PVurps/hH37ICPcUCa9Kf6j23sLFjuEo97wK+oQ4I ftrskooWaei7poESd/r1s7tFRUiFwppy4U/XlmiQiklgdl0bXJMsEEPyeOZ+gWiVNmIT +7IDzk3UV/CUDWU16ENVA23rZxj/5SM9XmtJ6UC0a89t0nO61WVYQr7p6w56w47V5xym ukcHj1Hlux3gkVLiQrR4fIkYEyEtM6bVFRprHmaSm1RuOdcR9p2PfnDC3V7X1PUidyTq Lh9CkoX0cs61qP6G4G6/2X/lzMN4RZBezJasSYtFxi4filFV8wdlY0ok4Y2qpf+Azzp3 dDlQ== X-Gm-Message-State: ALoCoQl8kzCM8TzZqrONkEYPlbjZYXQdZSFZSs16B9CIFGYlrnbrT09Bp9QrLaZcRaQ55s+HYFsw X-Received: by 10.68.110.196 with SMTP id ic4mr5105826pbb.84.1383342300494; Fri, 01 Nov 2013 14:45:00 -0700 (PDT) Received: from [192.168.1.38] (ppp-115-87-127-47.revip4.asianet.co.th. [115.87.127.47]) by mx.google.com with ESMTPSA id nj9sm12881036pbc.13.2013.11.01.14.44.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Nov 2013 14:44:59 -0700 (PDT) Message-ID: <52742115.9010404@pathscale.com> Date: Sat, 02 Nov 2013 04:45:57 +0700 From: =?ISO-8859-1?Q?=22C=2E_Bergstr=F6m=22?= User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20130802 Thunderbird/17.0.8 MIME-Version: 1.0 To: Alexey Dokuchaev Subject: Re: SSE2 intrinsics: gcc46 vs. clang contradiction References: <20131101124645.GA73456@regency.nsu.ru> <20131101154320.GA11359@regency.nsu.ru> In-Reply-To: <20131101154320.GA11359@regency.nsu.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 21:45:06 -0000 On 11/ 1/13 10:43 PM, Alexey Dokuchaev wrote: > On Fri, Nov 01, 2013 at 07:46:45PM +0700, Alexey Dokuchaev wrote: >> What adds to confusion, in their manual [1] Intel spells them differently >> themselves: first, in the table, it says: >> >> _mm_movpi64_epi64 Move MOVDQ2Q >> ^^^^^ >> >> Then later, when they describe what it does, it says: >> >> __m128i _mm_movpi64_pi64(__m64 a) >> ^^^^ >> Moves the 64 bits of a to the lower 64 bits of the result, zeroing the >> upper bits. > Microsoft (http://msdn.microsoft.com/en-us/library/has3d153(v=vs.90).aspx) > defines these two: > > _mm_movepi64_pi64 MOVDQ2Q Move > _mm_movpi64_epi64 MOVQ2DQ Move > > That is: > > __m64 _mm_movepi64_pi64 (__m128i a); > MOVDQ2Q > r0 := a0 ; > > __m128i _mm_movpi64_epi64 (__m64 a); > MOVDQ2Q > r0 := a0 ; r1 := 0X0 ; > > Cf. Intel's: > > _mm_movepi64_pi64 Move MOVDQ2Q > _mm_movpi64_epi64 Move MOVDQ2Q > > __m64 _mm_movepi64_pi64(__m128i a) > Returns the lower 64 bits of a as an __m64 type: R0 := a0 > > __m128i _mm_movpi64_pi64(__m64 a) > Moves the 64 bits of a to the lower 64 bits > of the result, zeroing the upper bits: R0 := a0, R1 = 0X0 > > Assuming that both documents correctly assign instructions to function > names (bonus clue: it also makes them symmetrical), then _mm_movpi64_pi64 > is indeed a typo and Clang's header is wrong, while GCC's is correct: it > should read _mm_movpi64_epi64(), not _mm_movpi64_pi64(). Why isn't this being asked on the clang or llvm mailing list? Wouldn't this impact upstream as well? From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 2 00:08:02 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 22B4750D for ; Sat, 2 Nov 2013 00:08:02 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BBF14220A for ; Sat, 2 Nov 2013 00:08:01 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::174:a45e:dad6:ebfd] (unknown [IPv6:2001:7b8:3a7:0:174:a45e:dad6:ebfd]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 437875C45; Sat, 2 Nov 2013 01:07:58 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_DF9A7AA5-2FDA-458D-9DC4-3ABF13DF6A07"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) Subject: Re: SSE2 intrinsics: gcc46 vs. clang contradiction From: Dimitry Andric In-Reply-To: <52742115.9010404@pathscale.com> Date: Sat, 2 Nov 2013 01:07:47 +0100 Message-Id: References: <20131101124645.GA73456@regency.nsu.ru> <20131101154320.GA11359@regency.nsu.ru> <52742115.9010404@pathscale.com> To: =?iso-8859-1?Q?=22C=2E_Bergstr=F6m=22?= X-Mailer: Apple Mail (2.1816) Cc: Alexey Dokuchaev , hackers@freebsd.org, cfe-commits@cs.uiuc.edu X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 00:08:02 -0000 --Apple-Mail=_DF9A7AA5-2FDA-458D-9DC4-3ABF13DF6A07 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 01 Nov 2013, at 22:45, C. Bergstr=F6m = wrote: > On 11/ 1/13 10:43 PM, Alexey Dokuchaev wrote: >> On Fri, Nov 01, 2013 at 07:46:45PM +0700, Alexey Dokuchaev wrote: >>> What adds to confusion, in their manual [1] Intel spells them = differently >>> themselves: first, in the table, it says: >>>=20 >>> _mm_movpi64_epi64 Move MOVDQ2Q >>> ^^^^^ >>>=20 >>> Then later, when they describe what it does, it says: >>>=20 >>> __m128i _mm_movpi64_pi64(__m64 a) >>> ^^^^ >>> Moves the 64 bits of a to the lower 64 bits of the result, zeroing = the >>> upper bits. >> Microsoft = (http://msdn.microsoft.com/en-us/library/has3d153(v=3Dvs.90).aspx) >> defines these two: >>=20 >> _mm_movepi64_pi64 MOVDQ2Q Move >> _mm_movpi64_epi64 MOVQ2DQ Move >>=20 >> That is: >>=20 >> __m64 _mm_movepi64_pi64 (__m128i a); >> MOVDQ2Q >> r0 :=3D a0 ; >>=20 >> __m128i _mm_movpi64_epi64 (__m64 a); >> MOVDQ2Q >> r0 :=3D a0 ; r1 :=3D 0X0 ; >>=20 >> Cf. Intel's: >>=20 >> _mm_movepi64_pi64 Move MOVDQ2Q >> _mm_movpi64_epi64 Move MOVDQ2Q >>=20 >> __m64 _mm_movepi64_pi64(__m128i a) >> Returns the lower 64 bits of a as an __m64 type: R0 :=3D a0 >>=20 >> __m128i _mm_movpi64_pi64(__m64 a) >> Moves the 64 bits of a to the lower 64 bits >> of the result, zeroing the upper bits: R0 :=3D a0, R1 =3D= 0X0 >>=20 >> Assuming that both documents correctly assign instructions to = function >> names (bonus clue: it also makes them symmetrical), then = _mm_movpi64_pi64 >> is indeed a typo and Clang's header is wrong, while GCC's is correct: = it >> should read _mm_movpi64_epi64(), not _mm_movpi64_pi64(). > Why isn't this being asked on the clang or llvm mailing list? Wouldn't = this impact upstream as well? Indeed, so redirecting to the cfe-commits list. It looks like this = incorrect function name has been in emmintrin.h since clang r61443 (by = andersca). Basically, we need the typo fixed as follows: Index: tools/clang/lib/Headers/emmintrin.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- tools/clang/lib/Headers/emmintrin.h (revision 193039) +++ tools/clang/lib/Headers/emmintrin.h (working copy) @@ -1366,7 +1366,7 @@ _mm_movepi64_pi64(__m128i __a) } static __inline__ __m128i __attribute__((__always_inline__, = __nodebug__)) -_mm_movpi64_pi64(__m64 __a) +_mm_movpi64_epi64(__m64 __a) { return (__m128i){ (long long)__a, 0 }; } Is this OK? -Dimitry --Apple-Mail=_DF9A7AA5-2FDA-458D-9DC4-3ABF13DF6A07 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlJ0QlwACgkQsF6jCi4glqNxKgCggpYbVbwFv7WfDirtup04XUw6 0YwAnRfBHUAF3BP5+MNVb6DquYtH4MKM =RRCu -----END PGP SIGNATURE----- --Apple-Mail=_DF9A7AA5-2FDA-458D-9DC4-3ABF13DF6A07-- From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 2 23:21:16 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 23B06235 for ; Sat, 2 Nov 2013 23:21:16 +0000 (UTC) (envelope-from bounces+73574-4a99-freebsd-hackers=freebsd.org@sendgrid.me) Received: from o3.shared.sendgrid.net (o3.shared.sendgrid.net [208.117.48.85]) by mx1.freebsd.org (Postfix) with SMTP id D4E1C2E70 for ; Sat, 2 Nov 2013 23:21:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h=from:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpapi; bh=Om/K1Mobz8hiEoWg84gWQ7zUNfA=; b=NvuE1P8HRN7/8EyLz0 ioxJOFGFYa1JfO3CM/OH1QtmjE0SCy1dhHYrxOfrnHXwTQbeZaMr2XAyLz8GT85J DwVjmf3Q13e4DwH3Y9qITCLs3j0dZpG83d4gUjB701lwtjiRjqqC7wxNw6EtdJjP +PEWTUOckprqlztvTMhoHjuDk= Received: by mf70.sendgrid.net with SMTP id mf70.26406.527588EA2 Sat, 02 Nov 2013 23:21:14 +0000 (GMT) Received: from mail.tarsnap.com (unknown [10.60.208.13]) by mi25 (SG) with ESMTP id 1421b1ed30e.3f5.11a7d8 for ; Sat, 02 Nov 2013 18:21:14 -0500 (CST) Received: (qmail 80614 invoked from network); 2 Nov 2013 23:21:13 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 2 Nov 2013 23:21:13 -0000 Received: (qmail 32642 invoked from network); 2 Nov 2013 23:19:42 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 2 Nov 2013 23:19:42 -0000 Message-ID: <5275888E.6010806@freebsd.org> Date: Sat, 02 Nov 2013 16:19:42 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: dt71@gmx.com, freebsd-hackers@freebsd.org Subject: Re: Automated submission of kernel panic reports References: <526F8EB3.1040205@freebsd.org> <5271A465.2030206@gmx.com> In-Reply-To: <5271A465.2030206@gmx.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SG-EID: W2XBZA0V/n0voZZ6SjDkgjXvzGvkLIaljy40FLIRIHTVMXCc7ynl2WKQUz0qqp0c6K6LL1z6j1zTauH4+OrnUMDRgIM1ZGYXMDHZG/Tfx81HhI2DYx7nSMFYARosvcOXrTVR3q/hwr+I8dciArCecFkadYhjBZufsLBwhwA5+G4= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 23:21:16 -0000 On 10/30/13 17:29, dt71@gmx.com wrote: > This smells of having a potential to make an admin accidentally transmit > undesired information, as well as adding some attack surface. The default behaviour is to send the information to root with instructions to forward it if there is nothing overly sensitive. If you can't deliver email to root securely, you're leaking lots of information already. I'm not sure what you mean by "adding some attack surface", can you elaborate? > Without testing, I bet that a reguler user will be able to read the panicmail.N > file (which will contain the textdump) -- the umask/permissions are not set up > properly. Oops, good catch. > I very much dislike the non-use of double quotes around variable expansions and > things like that in the shell code. Is there anywhere in particular you think this is dangerous? > The return code of /usr/local/bin/pkesh should be handled. Fixed. > Place a comment to the location in the code where an admin could put an add-on > script that can automatically modify the text to be submitted (both automatic > and confirmed mode). Given that these panic reports will be parsed by automated tools, I don't want to encourage people to modify what's submitted -- I'd prefer that people either accept or do not accept the submission of the data. > What if the /var/crash/{info,vmcore}.last symlinks were used as a basis for > selecting the last dump, instead of the current "$((`cat bounds` - 1))"/"$1" > method? Good point -- I'm still running 9.2 on my laptop and I hadn't noticed the new .last symlinks. > What's wrong with "our" /bin/sh? I'm not sure, but that comment appears in /usr/sbin/crashinfo: # XXX: /bin/sh on 7.0+ is broken so we can't simply pipe the commands to # kgdb via stdin and have to use a temporary file instead. > If a temporary file is used for kgdb commands > anyway, would it not be cleaner to use ``-x ${tmpfile}'' instead of input-piping? That option doesn't seem to exist. > How about: ${panicmail_sendto} could be "Full Name "? Good idea. > "# Remove temporary file" is a bit superfluous. I tend to over-comment. It's just my style... > Choose a consistent commenting style: either use periods/fullstops, or don't. Fixed, thanks. > I'd personally use ``>'' instead of ``>>'' first in panicmail_gather(). Yes, that was a mistake. Thanks for the great review! -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 2 23:34:08 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1E4DD51F for ; Sat, 2 Nov 2013 23:34:08 +0000 (UTC) (envelope-from dt71@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 93BA82EE6 for ; Sat, 2 Nov 2013 23:34:07 +0000 (UTC) Received: from [157.181.98.186] ([157.181.98.186]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LzcIM-1VhgKd3qkM-014mcS for ; Sun, 03 Nov 2013 00:34:06 +0100 Message-ID: <52758BCD.1000307@gmx.com> Date: Sun, 03 Nov 2013 00:33:33 +0100 From: dt71@gmx.com User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Firefox/24.0 SeaMonkey/2.21 MIME-Version: 1.0 To: Colin Percival , freebsd-hackers@freebsd.org Subject: Re: Automated submission of kernel panic reports References: <526F8EB3.1040205@freebsd.org> <5271A465.2030206@gmx.com> <5275888E.6010806@freebsd.org> In-Reply-To: <5275888E.6010806@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:weDpP9+IQM8vXS9SgSNTdDHoT23IOOvJVNj2YuudZGC4WcUQbP3 sws4mue+gm5JCTvmHfctjaRpP4Ob1kkIta5y403zfiz5aH344zFfccWyZScTuGawOBq6Vif 4W7QCO/P2Y9sWyWETfz4/J4oFqy235btcweSaihT8mFCl1k6axFM15H4Sjhlf+oQGND7b7o 13boriSgw4lOAiPO7RdOw== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 23:34:08 -0000 Colin Percival wrote, On 11/03/2013 00:19: > On 10/30/13 17:29, dt71@gmx.com wrote: >> I very much dislike the non-use of double quotes around variable expansions and >> things like that in the shell code. > > Is there anywhere in particular you think this is dangerous? No, but you never know... especially with non-standard system setups. From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 2 23:36:28 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EDAA1611 for ; Sat, 2 Nov 2013 23:36:28 +0000 (UTC) (envelope-from bounces+73574-4a99-freebsd-hackers=freebsd.org@sendgrid.me) Received: from o3.shared.sendgrid.net (o3.shared.sendgrid.net [208.117.48.85]) by mx1.freebsd.org (Postfix) with SMTP id 9DA9A2EFD for ; Sat, 2 Nov 2013 23:36:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.info; h=from:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpapi; bh=aHUQW2P1BavsxIo44tOy3i6Bg/w=; b=Z8IUZKyuY6VemcBGU3 1k6k6CkpaZeTt1q6Qv9fcXQN+4DbcKMLXJQoqb+N9R4O5T50mVJEw9BuReGGIanV Ssl+e8Imhj0GXBDAzDn/XnacrTDyFvBBcWeiRaf/qBjSXuMPIckOS2S3ihOW/o07 x0diNgS/K88JyLjtBEOqrxR/s= Received: by mf90 with SMTP id mf90.19231.52758C7B1 Sat, 02 Nov 2013 23:36:27 +0000 (GMT) Received: from mail.tarsnap.com (unknown [10.60.208.13]) by mi48 (SG) with ESMTP id 1421b2cc238.209a.1c1ece for ; Sat, 02 Nov 2013 18:36:27 -0500 (CST) Received: (qmail 81164 invoked from network); 2 Nov 2013 23:36:26 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by ec2-107-20-205-189.compute-1.amazonaws.com with ESMTP; 2 Nov 2013 23:36:26 -0000 Received: (qmail 32735 invoked from network); 2 Nov 2013 23:34:55 -0000 Received: from unknown (HELO clamshell.daemonology.net) (127.0.0.1) by clamshell.daemonology.net with SMTP; 2 Nov 2013 23:34:55 -0000 Message-ID: <52758C1F.9080601@freebsd.org> Date: Sat, 02 Nov 2013 16:34:55 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: dt71@gmx.com, freebsd-hackers@freebsd.org Subject: Re: Automated submission of kernel panic reports References: <526F8EB3.1040205@freebsd.org> <5271A465.2030206@gmx.com> <5275888E.6010806@freebsd.org> <52758BCD.1000307@gmx.com> In-Reply-To: <52758BCD.1000307@gmx.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SG-EID: W2XBZA0V/n0voZZ6SjDkgjXvzGvkLIaljy40FLIRIHTVMXCc7ynl2WKQUz0qqp0cTlIbOM/0L54z4Oz1eEZl8DslsTTWIKJRulcn6xziG1crSjXwfuyS+f+VT2/jPI7Q81AzvWanu4KJ+7sAbF1lSp3yvHXTKbLf4lFE69tm3dY= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 23:36:29 -0000 On 11/02/13 16:33, dt71@gmx.com wrote: > Colin Percival wrote, On 11/03/2013 00:19: >> On 10/30/13 17:29, dt71@gmx.com wrote: >>> I very much dislike the non-use of double quotes around variable expansions and >>> things like that in the shell code. >> >> Is there anywhere in particular you think this is dangerous? > > No, but you never know... especially with non-standard system setups. Quite true. I've committed an update including paranoid quoting. Let me know if you see anything I missed. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid