From owner-freebsd-hackers@freebsd.org Tue Jul 17 12:12:43 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5E3CF103D5B4 for ; Tue, 17 Jul 2018 12:12:43 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E854386934 for ; Tue, 17 Jul 2018 12:12:42 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from [88.198.220.130] (helo=sslproxy01.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1ffOqH-0005e0-PI for freebsd-hackers@freebsd.org; Tue, 17 Jul 2018 14:12:33 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy01.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1ffOqH-0002FI-JN for freebsd-hackers@freebsd.org; Tue, 17 Jul 2018 14:12:33 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id D23732A1685 for ; Tue, 17 Jul 2018 14:12:33 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id jtGAc9wjzFMn for ; Tue, 17 Jul 2018 14:12:33 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 984BF2A1686 for ; Tue, 17 Jul 2018 14:12:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id upndOo4V77vw for ; Tue, 17 Jul 2018 14:12:33 +0200 (CEST) Received: from linux-diu0.suse (unknown [192.168.96.149]) by mail.embedded-brains.de (Postfix) with ESMTP id 7965E2A1685 for ; Tue, 17 Jul 2018 14:12:33 +0200 (CEST) From: Sebastian Huber To: freebsd-hackers@freebsd.org Subject: [PATCH] Add fallthrough comment to kvprintf() Date: Tue, 17 Jul 2018 14:12:32 +0200 Message-Id: <20180717121232.18799-1-sebastian.huber@embedded-brains.de> X-Mailer: git-send-email 2.13.7 X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.100.0/24760/Tue Jul 17 06:40:15 2018) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 12:12:43 -0000 STYLE(9) recommends a FALLTHROUGH comment. Coverity Scan also complained about this area. --- sys/kern/subr_prf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sys/kern/subr_prf.c b/sys/kern/subr_prf.c index 618d47fe81a..e93aa9cc44c 100644 --- a/sys/kern/subr_prf.c +++ b/sys/kern/subr_prf.c @@ -716,6 +716,7 @@ reswitch: switch (ch = (u_char)*fmt++) { padc = '0'; goto reswitch; } + /* FALLTHROUGH */ case '1': case '2': case '3': case '4': case '5': case '6': case '7': case '8': case '9': for (n = 0;; ++fmt) { -- 2.13.7 From owner-freebsd-hackers@freebsd.org Tue Jul 17 12:14:16 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EB22F103D6F1 for ; Tue, 17 Jul 2018 12:14:15 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 857F186B21 for ; Tue, 17 Jul 2018 12:14:15 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from [88.198.220.130] (helo=sslproxy01.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1ffOru-0005fy-FX for freebsd-hackers@freebsd.org; Tue, 17 Jul 2018 14:14:14 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy01.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1ffOru-0005gR-8v for freebsd-hackers@freebsd.org; Tue, 17 Jul 2018 14:14:14 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 810CD2A1685 for ; Tue, 17 Jul 2018 14:14:14 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 2OpXsmpf_R-O for ; Tue, 17 Jul 2018 14:14:14 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 491C32A1686 for ; Tue, 17 Jul 2018 14:14:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id j7GPYIccXvfg for ; Tue, 17 Jul 2018 14:14:14 +0200 (CEST) Received: from [192.168.96.149] (unknown [192.168.96.149]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 280682A1685 for ; Tue, 17 Jul 2018 14:14:14 +0200 (CEST) To: FreeBSD From: Sebastian Huber Subject: Mailing list for NVMe driver topics? Message-ID: Date: Tue, 17 Jul 2018 14:14:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.100.0/24760/Tue Jul 17 06:40:15 2018) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 12:14:16 -0000 Hello, what is the right mailing list for NVMe driver topics? --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=C3=A4ftliche Mitteilung im Sinne des EHUG= . From owner-freebsd-hackers@freebsd.org Tue Jul 17 14:58:10 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD39B1042BF9 for ; Tue, 17 Jul 2018 14:58:10 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 303828CAAA for ; Tue, 17 Jul 2018 14:58:10 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pf0-x242.google.com with SMTP id c21-v6so630900pfn.8 for ; Tue, 17 Jul 2018 07:58:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=yPGorZdkUzrt1xeYZ5LzUzv/uYj5MMO0VG7be1GTHoQ=; b=dmLXbgRjTME4nJBpJ1GZhTV4OzpNTTqsZSEzk8iPCXtuhyzVfhEHeHNWMxH+UY5sBK Im3nVd/KnAIHxQPMNc+S7jqifAxrDWyY0bMdP7getnAtbjq4mHBia2wcfZ+Jl4W2QNSL W3kdIpdVh4b6Mkj5pYBRNZvuct7olz+YqIsXBjBdj7HbqFxO6Svi+3EECQHwtnah9On+ x7jNsQ+jpSsXxA3Ngngwar3MZOzO92O2mnLMVnFSnwfs76GV3TL/DIzO31dSS1V2+2RR zKLL9r5w55/OJVZ9F5Q66oCi9nvGhKZnul+FJirwyM7zi9kvtqTsEt8yOnOJIWZmk+cv gYmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=yPGorZdkUzrt1xeYZ5LzUzv/uYj5MMO0VG7be1GTHoQ=; b=NbXd1qMbTRht1ZRdQRjonGL+EOk8iDjky/aFBhjj+oLu+Hvmy91/duDarYGYhf0V4M 2N/miOvwXgji+8WrUoyTuAldcZhvXc3gbcoQCcYPhDSEQlgiuDE/TdubVEvkvKDKWhpS 0VqRbExrivNezC0CSbG7wyDtEp0M/wXwAoh85Qcdq7zCyfNM8oEdkdGiDTnlEQiFnXxh Q4heKrtBuRRW7Q/aBZnPJ4PJs+U4rivJlkaFUZvZAT/dJ2wMGBjRrQ138tp+WEHLC+rn nztdCk3dkEOtfG3vI5zWcSSLUBXftZKtln3eCa86zndM/UOQ2FevjtPBBfrhc4A6wjmv KUyw== X-Gm-Message-State: AOUpUlHeH0OFkevJ0fzUvVozq1V7JLfEAORLfrI8AGwNqaIDCw71Ibn4 scPod6TUYxu1pOU2bLS5e7s= X-Google-Smtp-Source: AAOMgpe5heSi1y8TB2yY2TODGf+SiCATgckrH/YPNQLhce+8GOtS8X36pdAmfSvzqcI+WoQnZFM9bQ== X-Received: by 2002:a63:2246:: with SMTP id t6-v6mr1946595pgm.258.1531839489230; Tue, 17 Jul 2018 07:58:09 -0700 (PDT) Received: from raichu (toroon0560w-lp130-01-174-88-79-3.dsl.bell.ca. [174.88.79.3]) by smtp.gmail.com with ESMTPSA id n16-v6sm2253216pfi.127.2018.07.17.07.58.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jul 2018 07:58:08 -0700 (PDT) Sender: Mark Johnston Date: Tue, 17 Jul 2018 10:58:02 -0400 From: Mark Johnston To: Sebastian Huber Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] Add fallthrough comment to kvprintf() Message-ID: <20180717145802.GA4539@raichu> References: <20180717121232.18799-1-sebastian.huber@embedded-brains.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180717121232.18799-1-sebastian.huber@embedded-brains.de> User-Agent: Mutt/1.10.0 (2018-05-17) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 14:58:10 -0000 On Tue, Jul 17, 2018 at 02:12:32PM +0200, Sebastian Huber wrote: > STYLE(9) recommends a FALLTHROUGH comment. Coverity Scan also > complained about this area. > --- > sys/kern/subr_prf.c | 1 + > 1 file changed, 1 insertion(+) Committed in r336417, thanks. From owner-freebsd-hackers@freebsd.org Tue Jul 17 17:10:35 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D9BD310470B6 for ; Tue, 17 Jul 2018 17:10:35 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-io0-f178.google.com (mail-io0-f178.google.com [209.85.223.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6EC3D7108A for ; Tue, 17 Jul 2018 17:10:35 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-io0-f178.google.com with SMTP id z19-v6so1628458ioh.4 for ; Tue, 17 Jul 2018 10:10:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=b4NXE++2jEDIvwVqvFFasiSKBrozUe+66TSMRTim+ro=; b=spclXjGwrE7QlRcNfdYRvCbRfBmfI6+VPt5m5Z0SSGXeQUWDlCxDnuEsEoKyLxlouT QYaYCTog/czrLi8ko2qkn/WHutUUMOZ7BJwqCKWhL2mMtFlJJLSVSR9RD87jKTD1jPPX Ga3iUubnzpuSoVKH+AQEi/1/vZ6AGX2rVC2g7hd4wgQfnpai1/EeY8aRIZXvgwdNB/xS 4mk+zS8UR2WMPx2JnQL1HULwN2MKec5kX+RSdpE1/etnCpqLFV56O0tPyevvI9lRrYx8 G7wc7TFMy8sKRG1xgJA+nsN2GbtBR3xdvv7CIjwNaLsO+NEd/VvKM64iaFgG7VTjuXMO ZyAg== X-Gm-Message-State: AOUpUlEFeIY+526hmU/D58kBh3O+c/t1FQdnvPz/yAzY+Cix3W5cA8ac zdhhIo+gGCwEtGftZHm4pgPwjN7n X-Google-Smtp-Source: AAOMgpcNJ6p5EC5Chn5ulPnQeB01vjdrehGrba1xloYXA3fPDM/wlNfP6zBz9HllQQ2f62QaFosNHg== X-Received: by 2002:a6b:ac03:: with SMTP id v3-v6mr2175303ioe.71.1531847061473; Tue, 17 Jul 2018 10:04:21 -0700 (PDT) Received: from mail-it0-f49.google.com (mail-it0-f49.google.com. [209.85.214.49]) by smtp.gmail.com with ESMTPSA id f8-v6sm782725ioe.46.2018.07.17.10.04.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jul 2018 10:04:21 -0700 (PDT) Received: by mail-it0-f49.google.com with SMTP id d191-v6so15129249ite.1 for ; Tue, 17 Jul 2018 10:04:21 -0700 (PDT) X-Received: by 2002:a24:b34f:: with SMTP id z15-v6mr2339390iti.53.1531847061229; Tue, 17 Jul 2018 10:04:21 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 2002:a02:7e0a:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 10:04:20 -0700 (PDT) In-Reply-To: References: From: Conrad Meyer Date: Tue, 17 Jul 2018 10:04:20 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Mailing list for NVMe driver topics? To: Sebastian Huber Cc: FreeBSD Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 17:10:36 -0000 On Tue, Jul 17, 2018 at 5:14 AM, Sebastian Huber wrote: > Hello, > > what is the right mailing list for NVMe driver topics? Probably freebsd-scsi@freebsd.org. Best, Conrad From owner-freebsd-hackers@freebsd.org Wed Jul 18 07:07:19 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78189103B57A for ; Wed, 18 Jul 2018 07:07:19 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EDDF68C2C4 for ; Wed, 18 Jul 2018 07:07:18 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from [88.198.220.130] (helo=sslproxy01.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1ffgYN-0000D8-Kl for freebsd-hackers@freebsd.org; Wed, 18 Jul 2018 09:07:15 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy01.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1ffgYN-00075z-Ej for freebsd-hackers@freebsd.org; Wed, 18 Jul 2018 09:07:15 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 80FB52A1685 for ; Wed, 18 Jul 2018 09:07:16 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id G30y2MVITeV7 for ; Wed, 18 Jul 2018 09:07:16 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 3C29F2A1686 for ; Wed, 18 Jul 2018 09:07:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1YcpDndYuEzz for ; Wed, 18 Jul 2018 09:07:16 +0200 (CEST) Received: from [192.168.96.149] (unknown [192.168.96.149]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 1F8C22A1685 for ; Wed, 18 Jul 2018 09:07:16 +0200 (CEST) To: FreeBSD From: Sebastian Huber Subject: FreeBSD 12 Release Schedule? Message-ID: <73d20b07-3ffb-6c5e-044c-62494c4f9c84@embedded-brains.de> Date: Wed, 18 Jul 2018 09:07:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.100.0/24760/Tue Jul 17 06:40:15 2018) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 07:07:19 -0000 Hello, the page https://www.freebsd.org/releases/12.0R/schedule.html referenced by https://www.freebsd.org/releng/index.html does not exist. I was unable to find some release process dates a couple=20 of days ago, but not today. --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=C3=A4ftliche Mitteilung im Sinne des EHUG= . From owner-freebsd-hackers@freebsd.org Wed Jul 18 09:58:38 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE83410420FC for ; Wed, 18 Jul 2018 09:58:38 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward106o.mail.yandex.net (forward106o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::609]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 25A807290D for ; Wed, 18 Jul 2018 09:58:37 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mxback14g.mail.yandex.net (mxback14g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:93]) by forward106o.mail.yandex.net (Yandex) with ESMTP id B2E9C78AC62; Wed, 18 Jul 2018 12:58:34 +0300 (MSK) Received: from smtp2o.mail.yandex.net (smtp2o.mail.yandex.net [2a02:6b8:0:1a2d::26]) by mxback14g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id dVTFWHdbNS-wY8OXKmT; Wed, 18 Jul 2018 12:58:34 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1531907914; bh=vU8aubWwMXUaV3vEIImf/RnOCt2DgUbubhK1TAKErCI=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=f/ydKZ/h0wuz2yaP4pO81H78duVCeMcvcYb7ce2sNXL1SKjalw907uxdLmP2WReu4 LT0LID1nycl5bmNZuGJkk4xxp3FXZ8TnYJY3V8w0aOMC+qoizQlMJHGiBYHaAJhW2V I15j5ub3dG4fhnLbBjCfmRMXRw5GUDIcyE9q3/aE= Received: by smtp2o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id bY9KUuTNij-wXE8d1bb; Wed, 18 Jul 2018 12:58:33 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1531907913; bh=vU8aubWwMXUaV3vEIImf/RnOCt2DgUbubhK1TAKErCI=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=WpTxUpGwgdxhGA0ckokyRvz5zrKI833M6vYHxmKyHtoU9HwKnGddrMrRyW1t94HjZ 98mp7vCdHawxdVtL2REgpopH31AsYU0w9tehwYDvxEdrt7KRGV7ASLHvlbSJ6RedLy 9/ds9JhCnRmYEV22VdPkFqIJjer1JEeN2Vt59FK0= Authentication-Results: smtp2o.mail.yandex.net; dkim=pass header.i=@yandex.ru Subject: Re: FreeBSD 12 Release Schedule? To: Sebastian Huber , FreeBSD References: <73d20b07-3ffb-6c5e-044c-62494c4f9c84@embedded-brains.de> From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Autocrypt: addr=bu7cher@yandex.ru; prefer-encrypt=mutual; keydata= xsBNBEwBF1kBCADB9sXFhBEUy8qQ4X63Y8eBatYMHGEFWN9ypS5lI3RE6qQW2EYbxNk7qUC5 21YIIS1mMFVBEfvR7J9uc7yaYgFCEb6Sce1RSO4ULN2mRKGHP3/Sl0ijZEjWHV91hY1YTHEF ZW/0GYinDf56sYpDDehaBF5wkWIo1+QK5nmj3vl0DIDCMNd7QEiWpyLVwECgLX2eOAXByT8B bCqVhJGcG6iFP7/B9Ll6uX5gb8thM9LM+ibwErDBVDGiOgvfxqidab7fdkh893IBCXa82H9N CNwnEtcgzh+BSKK5BgvPohFMgRwjti37TSxwLu63QejRGbZWSz3OK3jMOoF63tCgn7FvABEB AAHNIkFuZHJleSBWLiBFbHN1a292IDxhZUBmcmVlYnNkLm9yZz7CwHsEEwECACUCGwMGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheABQJMB/ruAhkBAAoJEAHF6gQQyKF6MLwH/3Ri/TZl9uo0 SepYWXOnxL6EaDVXDA+dLb1eLKC4PRBBjX29ttQ0KaWapiE6y5/AfzOPmRtHLrHYHjd/aiHX GMLHcYRXD+5GvdkK8iMALrZ28X0JXyuuZa8rAxWIWmCbYHNSBy2unqWgTI04Erodk90IALgM 9JeHN9sFqTM6zalrMnTzlcmel4kcjT3lyYw3vOKgoYLtsLhKZSbJoVVVlvRlGBpHFJI5AoYJ SyfXoN0rcX6k9X7Isp2K50YjqxV4v78xluh1puhwZyC0p8IShPrmrp9Oy9JkMX90o6UAXdGU KfdExJuGJfUZOFBTtNIMNIAKfMTjhpRhxONIr0emxxDOwE0ETAEXWQEIAJ2p6l9LBoqdH/0J PEFDY2t2gTvAuzz+8zs3R03dFuHcNbOwjvWCG0aOmVpAzkRa8egn5JB4sZaFUtKPYJEQ1Iu+ LUBwgvtXf4vWpzC67zs2dDuiW4LamH5p6xkTD61aHR7mCB3bg2TUjrDWn2Jt44cvoYxj3dz4 S49U1rc9ZPgD5axCNv45j72tggWlZvpefThP7xT1OlNTUqye2gAwQravXpZkl5JG4eOqJVIU X316iE3qso0iXRUtO7OseBf0PiVmk+wCahdreHOeOxK5jMhYkPKVn7z1sZiB7W2H2TojbmcK HZC22sz7Z/H36Lhg1+/RCnGzdEcjGc8oFHXHCxUAEQEAAcLAXwQYAQIACQUCTAEXWQIbDAAK CRABxeoEEMihegkYCAC3ivGYNe2taNm/4Nx5GPdzuaAJGKWksV+w9mo7dQvU+NmI2az5w8vw 98OmX7G0OV9snxMW+6cyNqBrVFTu33VVNzz9pnqNCHxGvj5dL5ltP160JV2zw2bUwJBYsgYQ WfyJJIM7l3gv5ZS3DGqaGIm9gOK1ANxfrR5PgPzvI9VxDhlr2juEVMZYAqPLEJe+SSxbwLoz BcFCNdDAyXcaAzXsx/E02YWm1hIWNRxanAe7Vlg7OL+gvLpdtrYCMg28PNqKNyrQ87LQ49O9 50IIZDOtNFeR0FGucjcLPdS9PiEqCoH7/waJxWp6ydJ+g4OYRBYNM0EmMgy1N85JJrV1mi5i Message-ID: <5a613a41-95a4-a69a-faa8-29144157766b@yandex.ru> Date: Wed, 18 Jul 2018 12:58:16 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <73d20b07-3ffb-6c5e-044c-62494c4f9c84@embedded-brains.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Jo2F1r0sIUtKsSMMU4lFhhZlVc2cuv6iS" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 09:58:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Jo2F1r0sIUtKsSMMU4lFhhZlVc2cuv6iS Content-Type: multipart/mixed; boundary="7y2wlH3ckDQWGnE97DTSjXQva4k61LSzy"; protected-headers="v1" From: "Andrey V. Elsukov" To: Sebastian Huber , FreeBSD Message-ID: <5a613a41-95a4-a69a-faa8-29144157766b@yandex.ru> Subject: Re: FreeBSD 12 Release Schedule? References: <73d20b07-3ffb-6c5e-044c-62494c4f9c84@embedded-brains.de> In-Reply-To: <73d20b07-3ffb-6c5e-044c-62494c4f9c84@embedded-brains.de> --7y2wlH3ckDQWGnE97DTSjXQva4k61LSzy Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 18.07.2018 10:07, Sebastian Huber wrote: > Hello, >=20 > the page >=20 > https://www.freebsd.org/releases/12.0R/schedule.html >=20 > referenced by >=20 > https://www.freebsd.org/releng/index.html >=20 > does not exist. I was unable to find some release process dates a coupl= e > of days ago, but not today. The basic schedule for 12.0 was head/ slush: August 10, 2018 head/ freeze: August 24, 2018 head/ KBI freeze: September 7, 2018 RELEASE announcement: November 6, 2018 --=20 WBR, Andrey V. Elsukov --7y2wlH3ckDQWGnE97DTSjXQva4k61LSzy-- --Jo2F1r0sIUtKsSMMU4lFhhZlVc2cuv6iS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAltPDz0ACgkQAcXqBBDI oXqHSQgAkbnxhbk9jxiCViLn+OSuCoMKbvwnffWFbamyZUdiqVMgBAtwUiujQ8Nn R28SxamIsduThvZZBNmaKrqPvxEuvQhjELrLxSJr3z5NnoZAjt17yKOOIrjBHDJd k+4UNreFTV0Ysj9WnrOH1Vixc20INJZHgszwUCC104ktEB1HeqbYnDwZqVhFrqQ0 1B+17K8NvAP75Ws4uhBAmINKwEYFBrKtGjwrVao+HOK8RfhMUq9H6hNxNNdKtMVR Dt7ZIpEeD5SKWy2qZca/8BXp85FurUkKr2Os3cGXQudtbeppNKA+Nx6fYCQNMzie IAO7QukPVQa3G13PAzP3QZvrS88W7g== =Pi69 -----END PGP SIGNATURE----- --Jo2F1r0sIUtKsSMMU4lFhhZlVc2cuv6iS-- From owner-freebsd-hackers@freebsd.org Wed Jul 18 12:31:48 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B550E104875D for ; Wed, 18 Jul 2018 12:31:48 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 640C777FA2; Wed, 18 Jul 2018 12:31:48 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 2D6AA4D44; Wed, 18 Jul 2018 12:31:48 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Wed, 18 Jul 2018 12:31:46 +0000 From: Glen Barber To: Sebastian Huber Cc: FreeBSD Subject: Re: FreeBSD 12 Release Schedule? Message-ID: <20180718123146.GI1377@FreeBSD.org> References: <73d20b07-3ffb-6c5e-044c-62494c4f9c84@embedded-brains.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PWfwoUCx3AFJRUBq" Content-Disposition: inline In-Reply-To: <73d20b07-3ffb-6c5e-044c-62494c4f9c84@embedded-brains.de> User-Agent: Mutt/1.9.1 (2017-09-22) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 12:31:48 -0000 --PWfwoUCx3AFJRUBq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 18, 2018 at 09:07:13AM +0200, Sebastian Huber wrote: > Hello, >=20 > the page >=20 > https://www.freebsd.org/releases/12.0R/schedule.html >=20 > referenced by >=20 > https://www.freebsd.org/releng/index.html >=20 > does not exist. I was unable to find some release process dates a couple = of > days ago, but not today. >=20 Huh. I'll take a look. I probably broke something with a recent-ish change. Glen --PWfwoUCx3AFJRUBq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAltPMzIACgkQAxRYpUeP 4pO1XA//fdUtlcngopJSYcb5+wXebw1FrdUWB3oNrTzYZtM/foLeBR6STFeuvCQd KSVR7RL9DJJ4HJGSxyXE0jyXy0GYI/S6bSLkmDhj6c0VP0N/lXeXaEXyLtvXWEue aPWsM436WS/d6lpOi6yU6lehW3KW4sUtMdLQWIITc+HgAdsPquFjmGEB4hBYtw3L d/1utK1FlLC38RUcCH6FTJvG2QX9Dg3ZCDGJqfDNTze2CqXtoXjLwPZicTb9UYv7 ZDS4EXtlZi45XlfEnHvm9mRBj0HjVCt48gjhKrdrdvEAMbIug3C1rM1p82aGm6OO al5ROLPFV31H9UNkHNLiimWrXJarOjuOga5+KfHxARihGOkZGFRRBLrpJd/L8oxw nw0HxIv0ex5gjpan4KK7EZR8sQzpTvcK5bH+KJTsAeOK7mcWdZAktoEMefh68Qx1 jNJpT/I81l2cmwovwHPAaUnIkE8j/HOZ3LvkBjaGu3902cMLCtsqwSouCLbwCDve szSQG3CFN1Q6vCc2fQldWj+MHOysDhcn1DaVg7+np1Hg+IpBiyyRci1Ciq6/eSSX Bx5hZxNqR30kVc05vmOGQjrlZ0OB0P7mBFVeclMb7Rh3j8SMRb/WrKuF9B5Es7tl pZtkjlnYP0CftwOxRFdt8YABM7TpGM06pgZopd85SeR2Y9qq5SY= =Fq2r -----END PGP SIGNATURE----- --PWfwoUCx3AFJRUBq-- From owner-freebsd-hackers@freebsd.org Wed Jul 18 12:35:25 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 30ED51048AC4 for ; Wed, 18 Jul 2018 12:35:25 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D93E27834B; Wed, 18 Jul 2018 12:35:24 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id A13714E4F; Wed, 18 Jul 2018 12:35:24 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Wed, 18 Jul 2018 12:35:22 +0000 From: Glen Barber To: Sebastian Huber Cc: FreeBSD Subject: Re: FreeBSD 12 Release Schedule? Message-ID: <20180718123522.GJ1377@FreeBSD.org> References: <73d20b07-3ffb-6c5e-044c-62494c4f9c84@embedded-brains.de> <20180718123146.GI1377@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pMCBjikF2xGw87uL" Content-Disposition: inline In-Reply-To: <20180718123146.GI1377@FreeBSD.org> User-Agent: Mutt/1.9.1 (2017-09-22) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 12:35:25 -0000 --pMCBjikF2xGw87uL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 18, 2018 at 12:31:46PM +0000, Glen Barber wrote: > On Wed, Jul 18, 2018 at 09:07:13AM +0200, Sebastian Huber wrote: > > Hello, > >=20 > > the page > >=20 > > https://www.freebsd.org/releases/12.0R/schedule.html > >=20 > > referenced by > >=20 > > https://www.freebsd.org/releng/index.html > >=20 > > does not exist. I was unable to find some release process dates a coupl= e of > > days ago, but not today. > >=20 >=20 > Huh. I'll take a look. I probably broke something with a recent-ish > change. >=20 Yep, it was definitely something I did that broke it. I'm looking into it. Glen --pMCBjikF2xGw87uL Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAltPNAoACgkQAxRYpUeP 4pPPyw/8Cfpsk4+rRmw/Qr4ZKPL6zEa7FGg9fx2tTUngd+oPu7OzkfLr7J55sH9O v3gPb11cTD3zK6t+BaokclRHfCRN0gmOoShnlrt0fvaI33IM7t19CQsD57C8T8D7 oMSwSEaLeEGlCO+h52mcn2RalvC47ZypkqpQ/VucyTaMwqPf84KvqQghP5sNJzA2 1HOKV4rWZyh1zlaINt6mvymHUhzQ7Hj1kDyaBe5FjkqCBDZbH7Pk271je32WFcjQ diZFl+hFDS4x7dgHsSYagOE7y+tB3OmAPodzs1Rnzcx9k3XIv0SCvigAEiH1eZsN JnXBEP6qZRWspI6wwEHid0O0sTh5aYKg64+FYQJHUgBNYyVz1qyhNke1wVGZAvhA ygVWnCwDIPI7cfSs93i6Y3FuNhffyCO1SPVseXRxFkLHicjX9sNt2LBzEgRVLT+o l46OYl75ZPNlB8DDoo6YbMRHUDqlcigFtscJNyB0w8OFt6Hgs14Ls1ue+jOCkreL q8LYKf2HW5UT0ixd+coXc6Akr3Wv0/QDeImiK+p6si0Nr5y3rKObe52NsseW8lEd HmLLP/aNS6i7xGbSzxWzVw70DJ0YTDpJAt6bpVc/kpCJFgDykzuuw713dAaJ1UaE +43kQI/ocqMJEdUevW9NPmOqSCHmu/buwuuSgVDNOuxA824SOdE= =OZAB -----END PGP SIGNATURE----- --pMCBjikF2xGw87uL-- From owner-freebsd-hackers@freebsd.org Wed Jul 18 14:52:01 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 21C4A104D19F for ; Wed, 18 Jul 2018 14:52:01 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C53817DA1E; Wed, 18 Jul 2018 14:52:00 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 8DE247249; Wed, 18 Jul 2018 14:52:00 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Wed, 18 Jul 2018 14:51:58 +0000 From: Glen Barber To: Sebastian Huber Cc: FreeBSD Subject: Re: FreeBSD 12 Release Schedule? Message-ID: <20180718145158.GK1377@FreeBSD.org> References: <73d20b07-3ffb-6c5e-044c-62494c4f9c84@embedded-brains.de> <20180718123146.GI1377@FreeBSD.org> <20180718123522.GJ1377@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZG5hGh9V5E9QzVHS" Content-Disposition: inline In-Reply-To: <20180718123522.GJ1377@FreeBSD.org> User-Agent: Mutt/1.9.1 (2017-09-22) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 14:52:01 -0000 --ZG5hGh9V5E9QzVHS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 18, 2018 at 12:35:22PM +0000, Glen Barber wrote: > On Wed, Jul 18, 2018 at 12:31:46PM +0000, Glen Barber wrote: > > On Wed, Jul 18, 2018 at 09:07:13AM +0200, Sebastian Huber wrote: > > > Hello, > > >=20 > > > the page > > >=20 > > > https://www.freebsd.org/releases/12.0R/schedule.html > > >=20 > > > referenced by > > >=20 > > > https://www.freebsd.org/releng/index.html > > >=20 > > > does not exist. I was unable to find some release process dates a cou= ple of > > > days ago, but not today. > > >=20 > >=20 > > Huh. I'll take a look. I probably broke something with a recent-ish > > change. > >=20 >=20 > Yep, it was definitely something I did that broke it. I'm looking into > it. >=20 Fixed as of r52018, and should be visible on the website again in the next 10 minutes or so. Thank you for the report. Glen --ZG5hGh9V5E9QzVHS Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAltPVAkACgkQAxRYpUeP 4pM+2g//cEXVvsvaQGVryrF24FhDhCYCD7YmGH5XojuR9CFDMWMQZAAoe41otLUC AcMjpugZijoRAs6HWsrts0XJYgZ4DpSbA2NAsl+CJNwcG2/6bs8XEkr6emd2G9FV TSY2QsELzJvccR99SAq1mRTJ8qQ5NE3XQc/aTtDteDmrZEmWctqg6n5N5fC0f8oZ NDzJQgb2CBglwJVSSiqqhcodcUgbS8LJ/mhOnFsTb4SRtwAWKeaiwvzfX0ym56wG rVUfGTGG83oyah1sDenkJ6aLZOoInVlHtd/RSR2ONGW715+YyXWbD8WLxpEj1s2f +bbk7Ir3qpvcvLZqmC0Pm2TWYUvxSkUpCGocWPF5WkYbP4XEp5sDgBX0ceyN4gYj AZLKvu0jdoeHoRFTrTtOHeDjJExsKgIysQABea57Rbx97q8IWq0BtAn1ThDMsC1v KopUeRn29/yjfCe8Cd9taSa9i+AMHRsyEFrLv11uYBA0SjP5GMjoKmAcem2jughl PtBnGHnLZiGnl8tdjaqNImpV23DOIA3iKRl1gxOqrLTG+PV6VteQtF+cc7jtDdo2 kJMmxCxbyE9azMQwGYubtMF2Gjqri+4OTj7xklsFD7zShXgs5TWrRAp8Ur5mGBsv WmfAdMlKStvOMaXF99P1um3pPWgArKloyxQL2kPipul3fpuqa1Q= =Vk+S -----END PGP SIGNATURE----- --ZG5hGh9V5E9QzVHS-- From owner-freebsd-hackers@freebsd.org Thu Jul 19 02:01:16 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 759911042D8A for ; Thu, 19 Jul 2018 02:01:16 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 1486D77DF1 for ; Thu, 19 Jul 2018 02:01:16 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id CDDE31042D86; Thu, 19 Jul 2018 02:01:15 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BB8B61042D85 for ; Thu, 19 Jul 2018 02:01:15 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 73E1177DEE for ; Thu, 19 Jul 2018 02:01:15 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1354) id 69F5511DF0; Thu, 19 Jul 2018 02:01:15 +0000 (UTC) From: Jan Beich To: hackers@FreeBSD.org Subject: Firefox 63 vs. sendmsg() Date: Thu, 19 Jul 2018 04:01:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 02:01:16 -0000 Can someone help debug https://bugzilla.mozilla.org/show_bug.cgi?id=1475970#c7 ? I'm not familar with socket code. Steps to reproduce: $ pkg install python27 $ hash git 2>/dev/null || pkg install mercurial $ hg clone https://hg.mozilla.org/mozilla-unified firefox || git clone https://github.com/mozilla/gecko-dev firefox $ cd firefox $ hg update central || git checkout origin/master $ fetch -qo- https://hg.mozilla.org/projects/nspr/raw-rev/776db96f834c | patch -Efsp1 -d nsprpub/ $ export CC=clang60 CXX=clang++60 $ ./mach bootstrap # select Firefox for Desktop $ ./mach build $ ./mach run -- if ./mach bootstrap fails due to rust try updating rust package instead, see https://clbin.com/n7tS9 From owner-freebsd-hackers@freebsd.org Thu Jul 19 09:36:09 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5C82102A52C for ; Thu, 19 Jul 2018 09:36:09 +0000 (UTC) (envelope-from jan.kokemueller@gmail.com) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A02887403 for ; Thu, 19 Jul 2018 09:36:09 +0000 (UTC) (envelope-from jan.kokemueller@gmail.com) Received: by mail-wm0-x22d.google.com with SMTP id y22-v6so5707864wma.0 for ; Thu, 19 Jul 2018 02:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:references:subject:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=kPknhHFbG90ZlMLhwamY9gSzhyaTSTbqOXuVU0OPGMg=; b=L8zW36ksU7GoYiZDo3qwF+POxYlwKLlW9uDqSMwdb8rHlpcGO1ruC02ugvvNmRFOV9 Omfv7+02NfJLFoorFA4sr3on2mfnFkTpJi3RNzyWjUZc272xK9D+R7xap36JYMnGhLan yBvtNXhszTaz7nKTvTBgLZH2mnQ2lgvFdPfSYkPme+wUgyuuqaw42SPVYitRL/sAGizC jqh1dirhaL00ZEdkJWd9q+2Mf3+tDxPhsYRxQj05cLAq6h27N27dfcCvYBJJ6IR0Sw9a h352D9FkhfAvzCqAUmvVxVwdV88DiNzeLda/PAwE16TC0N+xRsiqrmbQtPpEBHd+99uY gnBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:references:subject:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=kPknhHFbG90ZlMLhwamY9gSzhyaTSTbqOXuVU0OPGMg=; b=mAB6YR5ADIeiJRnoxaXuPwVfLjmWpSuiKOKJbVLl5F0xvl0dLjm3ySHaBTk4RQ+BTo 4khX/Uy9P6D+8biMqGxFLD7u5lfq8dy27H9152F4YNshlKgRpNlTmK1rvaA6zuS5VAX4 FLvunETdnV7v0yl4Ob1v9EiDeZfu081s2Ptq63LwGMkds7bZlornXAoxu8T5sOURDbVe 8vu5lfl5ulf/FQvK3oZDKUOaDF1j5kskNcBMcij2DAsrIDLbQnQCMLLxEAXCKoeYMzYf 5/gX5MjARGTcHgoAPHZiWtxNN+lp0CreIXhtSljGh1gLqKarsQOp1BVE/10+gQ4q0wuY eIKw== X-Gm-Message-State: AOUpUlE3rYUZSlBUe2QaxIspqcG6qeTg7us/R60sKyfU21jAXL6iq+/S ZNwooMGssZ/TgrGCIPxEutRXJUmE9Ys= X-Google-Smtp-Source: AAOMgpe6RahWKoXMeHGwrlVbk/4cqhbIVhCvYG04gaXcFIdwIUGQR9I75SC7EbBrtbQkw7kBBEHLpg== X-Received: by 2002:a1c:d844:: with SMTP id p65-v6mr3734926wmg.64.1531992966330; Thu, 19 Jul 2018 02:36:06 -0700 (PDT) Received: from [192.168.178.20] (p5B36CDDE.dip0.t-ipconnect.de. [91.54.205.222]) by smtp.googlemail.com with ESMTPSA id d102-v6sm8496667wma.10.2018.07.19.02.36.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jul 2018 02:36:05 -0700 (PDT) To: freebsd-hackers@freebsd.org References: Subject: Re: Firefox 63 vs. sendmsg() From: =?UTF-8?Q?Jan_Kokem=c3=bcller?= Message-ID: <844b824e-4463-82f4-a01d-5d398c4351e4@gmail.com> Date: Thu, 19 Jul 2018 11:36:04 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 19 Jul 2018 10:34:43 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 09:36:09 -0000 > Can someone help debug https://bugzilla.mozilla.org/show_bug.cgi?id=1475970#c7 ? > I'm not familar with socket code. Could it be related to this bug[1]? There is a demo program in another bug report[2] that still fails for me (running a recent -current, r334337). [1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=181741 [2]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215933 From owner-freebsd-hackers@freebsd.org Thu Jul 19 13:18:47 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 20D651035330 for ; Thu, 19 Jul 2018 13:18:47 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CA9F990CD1; Thu, 19 Jul 2018 13:18:46 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1354) id C32D81B20D; Thu, 19 Jul 2018 13:18:46 +0000 (UTC) From: Jan Beich To: Jan =?utf-8?Q?Kokem=C3=BCller?= Cc: freebsd-hackers@freebsd.org Subject: Re: Firefox 63 vs. sendmsg() References: <844b824e-4463-82f4-a01d-5d398c4351e4@gmail.com> Date: Thu, 19 Jul 2018 15:18:41 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 13:18:47 -0000 Jan Kokem=C3=BCller writes: >> Can someone help debug https://bugzilla.mozilla.org/show_bug.cgi?id=3D14= 75970#c7 ? >> I'm not familar with socket code. > > Could it be related to this bug[1]? > There is a demo program in another bug report[2] that still fails for me > (running a recent -current, r334337). > > [1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D181741 > [2]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215933 Indeed. Firefox 63 works fine after applying the patch in bug 181741. I wonder, if "packet loss" issue is also responsible for IPC instability in Firefox < 63 and Chromium. From owner-freebsd-hackers@freebsd.org Fri Jul 20 00:31:47 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 783A810521F4 for ; Fri, 20 Jul 2018 00:31:47 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 280E283A66; Fri, 20 Jul 2018 00:31:47 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from mousie.catspoiler.org (unknown [76.212.85.177]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: truckman) by smtp.freebsd.org (Postfix) with ESMTPSA id 64A60A7FA; Fri, 20 Jul 2018 00:31:46 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Date: Thu, 19 Jul 2018 17:31:44 -0700 (PDT) From: Don Lewis Subject: Re: Firefox 63 vs. sendmsg() To: Jan Beich cc: =?iso-8859-1?Q?Jan_Kokem=FCller?= , freebsd-hackers@freebsd.org In-Reply-To: Message-ID: References: <844b824e-4463-82f4-a01d-5d398c4351e4@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Disposition: INLINE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 00:31:47 -0000 On 19 Jul, Jan Beich wrote: > Jan Kokem=FCller writes: >=20 >>> Can someone help debug https://bugzilla.mozilla.org/show_bug.cgi?id=3D1= 475970#c7 ? >>> I'm not familar with socket code. >> >> Could it be related to this bug[1]? >> There is a demo program in another bug report[2] that still fails for me >> (running a recent -current, r334337). >> >> [1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D181741 >> [2]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215933 >=20 > Indeed. Firefox 63 works fine after applying the patch in bug 181741. > I wonder, if "packet loss" issue is also responsible for IPC instability > in Firefox < 63 and Chromium. I've been having terrible stability problems with Firefox on my 11.2-STABLE amd64 machine since upgrading to version 61. See: https://bugzilla.mozilla.org/show_bug.cgi?id=3D1476130 I applied this patch: https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D168943&action=3Ddif= f after tweaking it a bit so that all chunks would apply. It's too soon to tell for sure, but this fix appears promising. From owner-freebsd-hackers@freebsd.org Fri Jul 20 06:35:14 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D7CBF10335FD for ; Fri, 20 Jul 2018 06:35:13 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E3B58FC29; Fri, 20 Jul 2018 06:35:13 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1354) id 6DF11BB84; Fri, 20 Jul 2018 06:35:13 +0000 (UTC) From: Jan Beich To: Don Lewis Cc: Jan =?utf-8?Q?Kokem=C3=BCller?= , freebsd-hackers@freebsd.org Subject: Re: Firefox 63 vs. sendmsg() References: <844b824e-4463-82f4-a01d-5d398c4351e4@gmail.com> Date: Fri, 20 Jul 2018 08:35:09 +0200 In-Reply-To: (Don Lewis's message of "Thu, 19 Jul 2018 17:31:44 -0700 (PDT)") Message-ID: <7elq-l8iq-wny@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 06:35:14 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Don Lewis writes: > On 19 Jul, Jan Beich wrote: > >> Jan Kokem=C3=BCller writes: >>=20 >>>> Can someone help debug https://bugzilla.mozilla.org/show_bug.cgi?id=3D= 1475970#c7 ? >>>> I'm not familar with socket code. >>> >>> Could it be related to this bug[1]? >>> There is a demo program in another bug report[2] that still fails for me >>> (running a recent -current, r334337). >>> >>> [1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D181741 >>> [2]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215933 >>=20 >> Indeed. Firefox 63 works fine after applying the patch in bug 181741. >> I wonder, if "packet loss" issue is also responsible for IPC instability >> in Firefox < 63 and Chromium. > > I've been having terrible stability problems with Firefox on my > 11.2-STABLE amd64 machine since upgrading to version 61. See: > https://bugzilla.mozilla.org/show_bug.cgi?id=3D1476130 > I applied this patch: > https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D168943&action=3Dd= iff > after tweaking it a bit so that all chunks would apply. It's too soon > to tell for sure, but this fix appears promising. Can you attach the rebased version to bug 181741? I think, we may want to ask a few Chromium users to check if it has an impact on bug 212812. For comparison, attached to this mail is my own (blind) rebase. --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=sendmsg.diff Content-Description: bug 181741 patch series rebased against r336479 >From 8eeaf6d372dbc57c3f4d69b0e208d7b67703957f Mon Sep 17 00:00:00 2001 From: yuri Date: Sat, 2 Apr 2016 14:46:59 -0700 Subject: [PATCH 1/4] fix dropped control messages on uipc sockets There is the case when sendmsg(2) silently loses packets for AF_LOCAL domain when large packets with control part in them are sent. * Problem Description There is the watermark limit on sockbuf determined by net.local.stream.sendspace, default is 8192 bytes (field sockbuf.sb_hiwat). When sendmsg(2) sends large enough data (8K+ that hits this 8192 limit) with control message, sosend_generic will be cutting the message data into separate mbufs based on 'sbspace' (derived from the above-mentioned sb_hiwat limit) with adjustment for control message size as it sees it. This way it tries to make sure this sb_hiwat limit is enforced. However, down on uipc level control message is being further modified in two ways: unp_internalize modifies it into some 'internal' form, also unp_addsockcred function adds another control message when LOCAL_CREDS are requested by client. Both functions only increase control message size beyond its original size (seen by sosend_generic). So that the first final mbuf sent (concatenation of control and data) will always be larger than 'sbspace' limit that sosend_generic was cutting data for. There is also the function sbappendcontrol_locked. It checks the 'sbspace' limit again, and discards the packet when sbspace llimit is exceeded. Its result code is essentially ignored in uipc_send. I believe, sbappendcontrol_locked shouldn't be checking space at all, since packets are expected to be properly sized to begin with. But this won't be the right fix, since sizes would be exceeding the sbspace limit anyway. sosend_default is one level up over uipc level, and it doesn't know what uipc will do with control message. Therefore it can't know what the real adjustment for control message is needed (to properly cut data). It wrongly takes the original control size and this makes the first packet too large and discarded by sbappendcontrol_locked. * Patch synopsys - Added the new function into struct pr_usrreqs: int (*pru_finalizecontrol)(struct socket *so, int flags, struct mbuf **pcontrol); It is called by sosend_generic to update control message to its final form. - Removed 'sbspace' check from sbappendcontrol_locked. The only context it is called from is uipc_send, and all packet sizes are already conforming. - Fixed few wrong error codes relevant to this situation. [This patch is from: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=181741 but updated by Chris Torek to fit in a more recent FreeBSD kernel.] --- sys/kern/uipc_sockbuf.c | 21 +++--------- sys/kern/uipc_socket.c | 20 ++++++++++- sys/kern/uipc_usrreq.c | 76 ++++++++++++++++++++++++++++------------- sys/sys/protosw.h | 2 ++ sys/sys/sockbuf.h | 4 +-- 5 files changed, 81 insertions(+), 42 deletions(-) diff --git a/sys/kern/uipc_sockbuf.c b/sys/kern/uipc_sockbuf.c index f5da502612ba..0c946138f6ab 100644 --- a/sys/kern/uipc_sockbuf.c +++ b/sys/kern/uipc_sockbuf.c @@ -955,23 +955,16 @@ sbappendaddr(struct sockbuf *sb, const struct sockaddr *asa, return (retval); } -int +void sbappendcontrol_locked(struct sockbuf *sb, struct mbuf *m0, struct mbuf *control) { - struct mbuf *m, *n, *mlast; - int space; + struct mbuf *m, *mlast; SOCKBUF_LOCK_ASSERT(sb); - if (control == NULL) - panic("sbappendcontrol_locked"); - space = m_length(control, &n) + m_length(m0, NULL); - - if (space > sbspace(sb)) - return (0); m_clrprotoflags(m0); - n->m_next = m0; /* concatenate data to control */ + m_last(control)->m_next = m0; /* concatenate data to control */ SBLASTRECORDCHK(sb); @@ -985,18 +978,14 @@ sbappendcontrol_locked(struct sockbuf *sb, struct mbuf *m0, SBLASTMBUFCHK(sb); SBLASTRECORDCHK(sb); - return (1); } -int +void sbappendcontrol(struct sockbuf *sb, struct mbuf *m0, struct mbuf *control) { - int retval; - SOCKBUF_LOCK(sb); - retval = sbappendcontrol_locked(sb, m0, control); + sbappendcontrol_locked(sb, m0, control); SOCKBUF_UNLOCK(sb); - return (retval); } /* diff --git a/sys/kern/uipc_socket.c b/sys/kern/uipc_socket.c index 8952b1a4fdd4..4a3cd3e9bfda 100644 --- a/sys/kern/uipc_socket.c +++ b/sys/kern/uipc_socket.c @@ -1278,6 +1278,11 @@ sosend_dgram(struct socket *so, struct sockaddr *addr, struct uio *uio, KASSERT(so->so_proto->pr_flags & PR_ATOMIC, ("sosend_dgram: !PR_ATOMIC")); + if (so->so_proto->pr_usrreqs->pru_finalizecontrol && + (error = (*so->so_proto->pr_usrreqs->pru_finalizecontrol)(so, + flags, &control, td))) + goto out; + if (uio != NULL) resid = uio->uio_resid; else @@ -1342,10 +1347,14 @@ sosend_dgram(struct socket *so, struct sockaddr *addr, struct uio *uio, * problem and need fixing. */ space = sbspace(&so->so_snd); + SOCKBUF_UNLOCK(&so->so_snd); if (flags & MSG_OOB) space += 1024; + if (clen > space) { + error = EMSGSIZE; + goto out; + } space -= clen; - SOCKBUF_UNLOCK(&so->so_snd); if (resid > space) { error = EMSGSIZE; goto out; @@ -1440,6 +1449,11 @@ sosend_generic(struct socket *so, struct sockaddr *addr, struct uio *uio, int clen = 0, error, dontroute; int atomic = sosendallatonce(so) || top; + if (so->so_proto->pr_usrreqs->pru_finalizecontrol && + (error = (*so->so_proto->pr_usrreqs->pru_finalizecontrol)(so, + flags, &control, td))) + goto out; + if (uio != NULL) resid = uio->uio_resid; else @@ -1532,6 +1546,10 @@ sosend_generic(struct socket *so, struct sockaddr *addr, struct uio *uio, goto restart; } SOCKBUF_UNLOCK(&so->so_snd); + if (clen > space) { + error = EMSGSIZE; + goto release; + } space -= clen; do { if (uio == NULL) { diff --git a/sys/kern/uipc_usrreq.c b/sys/kern/uipc_usrreq.c index ac93ea1b9c4e..3f0bad36fe0c 100644 --- a/sys/kern/uipc_usrreq.c +++ b/sys/kern/uipc_usrreq.c @@ -313,7 +313,7 @@ static int unp_internalize(struct mbuf **, struct thread *); static void unp_internalize_fp(struct file *); static int unp_externalize(struct mbuf *, struct mbuf **, int); static int unp_externalize_fp(struct file *); -static struct mbuf *unp_addsockcred(struct thread *, struct mbuf *); +static int unp_addsockcred(struct mbuf **, struct thread *); static void unp_process_defers(void * __unused, int); @@ -953,6 +953,43 @@ uipc_peeraddr(struct socket *so, struct sockaddr **nam) return (0); } +static int +uipc_finalizecontrol(struct socket *so, int flags, struct mbuf **pcontrol, + struct thread *td) +{ + struct unpcb *unp, *unp2; + int error = 0; + + unp = sotounpcb(so); + KASSERT(unp != NULL, ("uipc_finalizecontrol: unp == NULL")); + + unp2 = unp->unp_conn; + + if (*pcontrol != NULL && (error = unp_internalize(pcontrol, td))) + return (error); + + /* Lockless read, ignore when not connected. */ + if (unp2 && unp2->unp_flags & UNP_WANTCRED) { + switch (so->so_type) { + case SOCK_SEQPACKET: + case SOCK_STREAM: + /* Credentials are passed only once on streams */ + UNP_PCB_LOCK(unp2); + if (unp2->unp_flags & UNP_WANTCRED) { + unp2->unp_flags &= ~UNP_WANTCRED; + error = unp_addsockcred(pcontrol, td); + } + UNP_PCB_UNLOCK(unp2); + break; + case SOCK_DGRAM: + error = unp_addsockcred(pcontrol, td); + break; + } + } + + return (error); +} + static int uipc_rcvd(struct socket *so, int flags) { @@ -1045,8 +1082,6 @@ uipc_send(struct socket *so, int flags, struct mbuf *m, struct sockaddr *nam, error = EOPNOTSUPP; goto release; } - if (control != NULL && (error = unp_internalize(&control, td))) - goto release; unp2 = NULL; switch (so->so_type) { @@ -1106,8 +1141,6 @@ uipc_send(struct socket *so, int flags, struct mbuf *m, struct sockaddr *nam, break; } connect_self: - if (unp2->unp_flags & UNP_WANTCRED) - control = unp_addsockcred(td, control); if (unp->unp_addr != NULL) from = (struct sockaddr *)unp->unp_addr; else @@ -1167,14 +1200,6 @@ uipc_send(struct socket *so, int flags, struct mbuf *m, struct sockaddr *nam, break; } SOCKBUF_LOCK(&so2->so_rcv); - if (unp2->unp_flags & UNP_WANTCRED) { - /* - * Credentials are passed only once on SOCK_STREAM - * and SOCK_SEQPACKET. - */ - unp2->unp_flags &= ~UNP_WANTCRED; - control = unp_addsockcred(td, control); - } /* * Send to paired receive port, and then reduce send buffer * hiwater marks to maintain backpressure. Wake up readers. @@ -1182,9 +1207,9 @@ uipc_send(struct socket *so, int flags, struct mbuf *m, struct sockaddr *nam, switch (so->so_type) { case SOCK_STREAM: if (control != NULL) { - if (sbappendcontrol_locked(&so2->so_rcv, m, - control)) - control = NULL; + sbappendcontrol_locked(&so2->so_rcv, m, + control); + control = NULL; } else sbappend_locked(&so2->so_rcv, m, flags); break; @@ -1205,6 +1230,7 @@ uipc_send(struct socket *so, int flags, struct mbuf *m, struct sockaddr *nam, break; } } + m = NULL; mbcnt = so2->so_rcv.sb_mbcnt; sbcc = sbavail(&so2->so_rcv); @@ -1225,7 +1251,6 @@ uipc_send(struct socket *so, int flags, struct mbuf *m, struct sockaddr *nam, so->so_snd.sb_flags |= SB_STOP; SOCKBUF_UNLOCK(&so->so_snd); UNP_PCB_UNLOCK(unp2); - m = NULL; break; } @@ -1360,6 +1385,7 @@ static struct pr_usrreqs uipc_usrreqs_dgram = { .pru_disconnect = uipc_disconnect, .pru_listen = uipc_listen, .pru_peeraddr = uipc_peeraddr, + .pru_finalizecontrol = uipc_finalizecontrol, .pru_rcvd = uipc_rcvd, .pru_send = uipc_send, .pru_sense = uipc_sense, @@ -1382,6 +1408,7 @@ static struct pr_usrreqs uipc_usrreqs_seqpacket = { .pru_disconnect = uipc_disconnect, .pru_listen = uipc_listen, .pru_peeraddr = uipc_peeraddr, + .pru_finalizecontrol = uipc_finalizecontrol, .pru_rcvd = uipc_rcvd, .pru_send = uipc_send, .pru_sense = uipc_sense, @@ -1404,6 +1431,7 @@ static struct pr_usrreqs uipc_usrreqs_stream = { .pru_disconnect = uipc_disconnect, .pru_listen = uipc_listen, .pru_peeraddr = uipc_peeraddr, + .pru_finalizecontrol = uipc_finalizecontrol, .pru_rcvd = uipc_rcvd, .pru_send = uipc_send, .pru_ready = uipc_ready, @@ -2025,7 +2053,7 @@ unp_externalize(struct mbuf *control, struct mbuf **controlp, int flags) SCM_RIGHTS, SOL_SOCKET); if (*controlp == NULL) { FILEDESC_XUNLOCK(fdesc); - error = E2BIG; + error = ENOBUFS; unp_freerights(fdep, newfds); goto next; } @@ -2202,7 +2230,7 @@ unp_internalize(struct mbuf **controlp, struct thread *td) SCM_RIGHTS, SOL_SOCKET); if (*controlp == NULL) { FILEDESC_SUNLOCK(fdesc); - error = E2BIG; + error = ENOBUFS; goto out; } fdp = data; @@ -2290,9 +2318,10 @@ unp_internalize(struct mbuf **controlp, struct thread *td) return (error); } -static struct mbuf * -unp_addsockcred(struct thread *td, struct mbuf *control) +static int +unp_addsockcred(struct mbuf **pcontrol, struct thread *td) { + struct mbuf *control = *pcontrol; struct mbuf *m, *n, *n_prev; struct sockcred *sc; const struct cmsghdr *cm; @@ -2302,7 +2331,7 @@ unp_addsockcred(struct thread *td, struct mbuf *control) ngroups = MIN(td->td_ucred->cr_ngroups, CMGROUP_MAX); m = sbcreatecontrol(NULL, SOCKCREDSIZE(ngroups), SCM_CREDS, SOL_SOCKET); if (m == NULL) - return (control); + return (ENOBUFS); sc = (struct sockcred *) CMSG_DATA(mtod(m, struct cmsghdr *)); sc->sc_uid = td->td_ucred->cr_ruid; @@ -2336,7 +2365,8 @@ unp_addsockcred(struct thread *td, struct mbuf *control) /* Prepend it to the head. */ m->m_next = control; - return (m); + *pcontrol = m; + return (0); } static struct unpcb * diff --git a/sys/sys/protosw.h b/sys/sys/protosw.h index 096b507776e1..b28ae286ff66 100644 --- a/sys/sys/protosw.h +++ b/sys/sys/protosw.h @@ -201,6 +201,8 @@ struct pr_usrreqs { int (*pru_listen)(struct socket *so, int backlog, struct thread *td); int (*pru_peeraddr)(struct socket *so, struct sockaddr **nam); + int (*pru_finalizecontrol)(struct socket *so, int flags, struct mbuf **pcontrol, + struct thread *td); int (*pru_rcvd)(struct socket *so, int flags); int (*pru_rcvoob)(struct socket *so, struct mbuf *m, int flags); int (*pru_send)(struct socket *so, int flags, struct mbuf *m, diff --git a/sys/sys/sockbuf.h b/sys/sys/sockbuf.h index ff7863da6055..ad452ad4f4ab 100644 --- a/sys/sys/sockbuf.h +++ b/sys/sys/sockbuf.h @@ -139,9 +139,9 @@ int sbappendaddr_locked(struct sockbuf *sb, const struct sockaddr *asa, struct mbuf *m0, struct mbuf *control); int sbappendaddr_nospacecheck_locked(struct sockbuf *sb, const struct sockaddr *asa, struct mbuf *m0, struct mbuf *control); -int sbappendcontrol(struct sockbuf *sb, struct mbuf *m0, +void sbappendcontrol(struct sockbuf *sb, struct mbuf *m0, struct mbuf *control); -int sbappendcontrol_locked(struct sockbuf *sb, struct mbuf *m0, +void sbappendcontrol_locked(struct sockbuf *sb, struct mbuf *m0, struct mbuf *control); void sbappendrecord(struct sockbuf *sb, struct mbuf *m0); void sbappendrecord_locked(struct sockbuf *sb, struct mbuf *m0); >From 767e783215ac8efc9925a15bcb2e5b83f90f5dcf Mon Sep 17 00:00:00 2001 From: Chris Torek Date: Sat, 2 Apr 2016 16:48:07 -0700 Subject: [PATCH 2/4] socket send: use correct control message length The new internalize function may (and actually does) replace a single control message mbuf with a chain, so we must use m_length() rather than just control->m_len. Add some comments to that effect. Also, while here, consolidate the send-space calculation (which adds an extra magic-number 1024 for out of band data) into a single inline, so that we have one magic constant instead of two. --- sys/kern/uipc_socket.c | 43 ++++++++++++++++++++++++++++++------------ sys/kern/uipc_usrreq.c | 10 ++++++++++ 2 files changed, 41 insertions(+), 12 deletions(-) diff --git a/sys/kern/uipc_socket.c b/sys/kern/uipc_socket.c index 4a3cd3e9bfda..a574c84195d8 100644 --- a/sys/kern/uipc_socket.c +++ b/sys/kern/uipc_socket.c @@ -1266,6 +1266,23 @@ sodisconnect(struct socket *so) #define SBLOCKWAIT(f) (((f) & MSG_DONTWAIT) ? 0 : SBL_WAIT) +/* + * Like sbspace(&so->so_snd), but allow extra room for MSG_OOB. + * + * It's not clear whether the magic 1024 number is sensible, but + * at least it's now in only one place. + */ +static inline int +sosend_space(struct socket *so, int flags) +{ + long space; + + space = sbspace(&so->so_snd); + if (flags & MSG_OOB) + space += 1024; + return (space); +} + int sosend_dgram(struct socket *so, struct sockaddr *addr, struct uio *uio, struct mbuf *top, struct mbuf *control, int flags, struct thread *td) @@ -1303,8 +1320,17 @@ sosend_dgram(struct socket *so, struct sockaddr *addr, struct uio *uio, (flags & MSG_DONTROUTE) && (so->so_options & SO_DONTROUTE) == 0; if (td != NULL) td->td_ru.ru_msgsnd++; + /* + * NB: Original user supplied control message may have + * fit and we may have made it too big when we finalized + * it, which will have us return EMSGSIZE below. This + * seems rude, but it is at least functional: the user + * can try sending smaller control values (mainly, fewer + * fd's at a time, as those are the ones that expand to + * twice their size on I32LP64 systems). + */ if (control != NULL) - clen = control->m_len; + clen = m_length(control, NULL); SOCKBUF_LOCK(&so->so_snd); if (so->so_snd.sb_state & SBS_CANTSENDMORE) { @@ -1342,14 +1368,8 @@ sosend_dgram(struct socket *so, struct sockaddr *addr, struct uio *uio, } } - /* - * Do we need MSG_OOB support in SOCK_DGRAM? Signs here may be a - * problem and need fixing. - */ - space = sbspace(&so->so_snd); + space = sosend_space(so, flags); SOCKBUF_UNLOCK(&so->so_snd); - if (flags & MSG_OOB) - space += 1024; if (clen > space) { error = EMSGSIZE; goto out; @@ -1479,7 +1499,7 @@ sosend_generic(struct socket *so, struct sockaddr *addr, struct uio *uio, if (td != NULL) td->td_ru.ru_msgsnd++; if (control != NULL) - clen = control->m_len; + clen = m_length(control, NULL); error = sblock(&so->so_snd, SBLOCKWAIT(flags)); if (error) @@ -1523,9 +1543,8 @@ sosend_generic(struct socket *so, struct sockaddr *addr, struct uio *uio, goto release; } } - space = sbspace(&so->so_snd); - if (flags & MSG_OOB) - space += 1024; + space = sosend_space(so, flags); + /* NB: control msg is implicitly atomic */ if ((atomic && resid > so->so_snd.sb_hiwat) || clen > so->so_snd.sb_hiwat) { SOCKBUF_UNLOCK(&so->so_snd); diff --git a/sys/kern/uipc_usrreq.c b/sys/kern/uipc_usrreq.c index 3f0bad36fe0c..e7da95fee7be 100644 --- a/sys/kern/uipc_usrreq.c +++ b/sys/kern/uipc_usrreq.c @@ -2140,6 +2140,16 @@ unp_init(void) UNP_DEFERRED_LOCK_INIT(); } +/* + * Convert incoming control message from user-supplied format + * to internal form. + * + * Note that when we're called, *controlp is a single mbuf + * whose m_len is the length of the cmsg data structures + * that have not yet been internalized. On return, *controlp + * is an mbuf chain whose individual mbufs are internalized; + * this chain may have a different length. + */ static int unp_internalize(struct mbuf **controlp, struct thread *td) { >From 2e3f20560ed12ffb277659562033ddb7e0c574ba Mon Sep 17 00:00:00 2001 From: Chris Torek Date: Sat, 2 Apr 2016 16:55:48 -0700 Subject: [PATCH 3/4] uipc_finalizecontrol: read-lock the unp link Alan Somers pointed out [1] that the socket linkage has a lock; we should grab it for form's sake, at least. While here, rewrite the code for clarity, and note a bug. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=181741#c7 --- sys/kern/uipc_usrreq.c | 52 +++++++++++++++++++++++++++--------------- 1 file changed, 33 insertions(+), 19 deletions(-) diff --git a/sys/kern/uipc_usrreq.c b/sys/kern/uipc_usrreq.c index e7da95fee7be..362b23ea6995 100644 --- a/sys/kern/uipc_usrreq.c +++ b/sys/kern/uipc_usrreq.c @@ -959,34 +959,48 @@ uipc_finalizecontrol(struct socket *so, int flags, struct mbuf **pcontrol, { struct unpcb *unp, *unp2; int error = 0; + bool wantcred, oneshot; unp = sotounpcb(so); KASSERT(unp != NULL, ("uipc_finalizecontrol: unp == NULL")); - unp2 = unp->unp_conn; - if (*pcontrol != NULL && (error = unp_internalize(pcontrol, td))) return (error); - /* Lockless read, ignore when not connected. */ - if (unp2 && unp2->unp_flags & UNP_WANTCRED) { - switch (so->so_type) { - case SOCK_SEQPACKET: - case SOCK_STREAM: - /* Credentials are passed only once on streams */ - UNP_PCB_LOCK(unp2); - if (unp2->unp_flags & UNP_WANTCRED) { - unp2->unp_flags &= ~UNP_WANTCRED; - error = unp_addsockcred(pcontrol, td); - } - UNP_PCB_UNLOCK(unp2); - break; - case SOCK_DGRAM: - error = unp_addsockcred(pcontrol, td); - break; - } + UNP_LINK_RLOCK(); + unp2 = unp->unp_conn; + UNP_LINK_RUNLOCK(); + + /* + * If not connected, we're done now (might be auto-connect + * on send, leave everything to caller). Otherwise, handle + * one-shot credentials on stream and seqpacket sockets here. + * + * XXX If the send fails, we never get another chance. + * We could restore UNP_WANTCRED if the unp_addsockcred() + * call fails here but we can't handle the more likely + * entire-send-fails case. Deferring clearing the flag + * is not a great solution either. Perhaps best would be + * to have an additional UNP_CREDS_SENT_SUCCESSFULLY flag + * and check that here. For now, just leave it this way. + */ + if (unp2 == NULL) + return (0); + + oneshot = so->so_type == SOCK_SEQPACKET || + so->so_type == SOCK_STREAM; + if (oneshot) { + UNP_PCB_LOCK(unp2); + wantcred = (unp2->unp_flags & UNP_WANTCRED) != 0; + unp2->unp_flags &= ~UNP_WANTCRED; + UNP_PCB_UNLOCK(unp2); + } else { + wantcred = true; } + if (wantcred) + error = unp_addsockcred(pcontrol, td); + return (error); } >From f200a14690619f6002c4bbf6b1152b2a50db0852 Mon Sep 17 00:00:00 2001 From: Chris Torek Date: Sat, 2 Apr 2016 19:23:32 -0700 Subject: [PATCH 4/4] rewrite unp_internalize() The existing code was nearly unreadable and probably buggy if you sent an SCM_RIGHTS control message with an empty fd list and then any subsequent SCM_* message. This moves the various internalizers into separate functions, so that the control path, where we operate on the outer control-message data, is firewalled off from the transforms, where we turn the sender's SCM_* messages into the internal SCM_* forms that go across the unp link to the other socket. --- sys/kern/uipc_usrreq.c | 385 +++++++++++++++++++++++++---------------- 1 file changed, 236 insertions(+), 149 deletions(-) diff --git a/sys/kern/uipc_usrreq.c b/sys/kern/uipc_usrreq.c index 362b23ea6995..8b81f5f2241f 100644 --- a/sys/kern/uipc_usrreq.c +++ b/sys/kern/uipc_usrreq.c @@ -2154,6 +2154,44 @@ unp_init(void) UNP_DEFERRED_LOCK_INIT(); } +/* + * Arguments passed to internalizer/transformer (ix = internal xform). + * The transformation function may fill in a new ix_mbuf. + */ +struct internalize_transform_data { + socklen_t ix_odatalen; /* original data length in bytes */ + socklen_t ix_ndatalen; /* new data length, or 0 */ + void *ix_odata; /* original data */ + void *ix_ndata; /* new data area, or NULL */ + struct mbuf *ix_mbuf; /* mbuf for new data */ + struct thread *ix_td; /* calling thread */ +}; + +/* + * Internalizers. If you provide a nonzero size, we pre-allocate + * the ix_mbuf and you get a nonzero ndatasize and non-NULL ndata. + */ +struct unp_scm_internalize_op { + socklen_t size; /* predefined output size, or 0 */ + int (*func)(struct internalize_transform_data *); +}; + +static int unp_internalize_creds(struct internalize_transform_data *); +static int unp_internalize_fds(struct internalize_transform_data *); +static int unp_internalize_timestamp(struct internalize_transform_data *); +static int unp_internalize_bintime(struct internalize_transform_data *); +static int unp_internalize_realtime(struct internalize_transform_data *); +static int unp_internalize_monotonic(struct internalize_transform_data *); + +static struct unp_scm_internalize_op unp_internalize_ops[] = { + [SCM_CREDS] = { sizeof(struct cmsgcred), unp_internalize_creds }, + [SCM_RIGHTS] = { 0, unp_internalize_fds }, + [SCM_TIMESTAMP] = { sizeof(struct timeval), unp_internalize_timestamp }, + [SCM_BINTIME] = { sizeof(struct bintime), unp_internalize_bintime }, + [SCM_REALTIME] = { sizeof(struct timespec), unp_internalize_realtime }, + [SCM_MONOTONIC] = { sizeof(struct timespec), unp_internalize_monotonic }, +}; + /* * Convert incoming control message from user-supplied format * to internal form. @@ -2163,185 +2201,234 @@ unp_init(void) * that have not yet been internalized. On return, *controlp * is an mbuf chain whose individual mbufs are internalized; * this chain may have a different length. + * + * Caller will always m_freem(*controlp), even if we return error. */ static int unp_internalize(struct mbuf **controlp, struct thread *td) { - struct mbuf *control = *controlp; - struct proc *p = td->td_proc; - struct filedesc *fdesc = p->p_fd; - struct bintime *bt; - struct cmsghdr *cm = mtod(control, struct cmsghdr *); - struct cmsgcred *cmcred; - struct filedescent *fde, **fdep, *fdev; - struct file *fp; - struct timeval *tv; - struct timespec *ts; - int i, *fdp; - void *data; - socklen_t clen = control->m_len, datalen; - int error, oldfds; - u_int newlen; + struct unp_scm_internalize_op *op; + struct internalize_transform_data ix; + struct cmsghdr *cm; + struct mbuf *control, *m; + void *odata; + int cmtype, error; + socklen_t clen, size, odatalen; UNP_LINK_UNLOCK_ASSERT(); + ix.ix_td = td; /* never changes, just passed through */ + error = 0; + control = *controlp; *controlp = NULL; - while (cm != NULL) { - if (sizeof(*cm) > clen || cm->cmsg_level != SOL_SOCKET - || cm->cmsg_len > clen || cm->cmsg_len < sizeof(*cm)) { - error = EINVAL; - goto out; - } - data = CMSG_DATA(cm); - datalen = (caddr_t)cm + cm->cmsg_len - (caddr_t)data; + clen = control->m_len; + cm = mtod(control, struct cmsghdr *); - switch (cm->cmsg_type) { + while (error == 0) { /* - * Fill in credential information. + * Verify current control message, and set up type + * and old data pointer and size values. */ - case SCM_CREDS: - *controlp = sbcreatecontrol(NULL, sizeof(*cmcred), - SCM_CREDS, SOL_SOCKET); - if (*controlp == NULL) { - error = ENOBUFS; - goto out; - } - cmcred = (struct cmsgcred *) - CMSG_DATA(mtod(*controlp, struct cmsghdr *)); - cmcred->cmcred_pid = p->p_pid; - cmcred->cmcred_uid = td->td_ucred->cr_ruid; - cmcred->cmcred_gid = td->td_ucred->cr_rgid; - cmcred->cmcred_euid = td->td_ucred->cr_uid; - cmcred->cmcred_ngroups = MIN(td->td_ucred->cr_ngroups, - CMGROUP_MAX); - for (i = 0; i < cmcred->cmcred_ngroups; i++) - cmcred->cmcred_groups[i] = - td->td_ucred->cr_groups[i]; + if (clen < sizeof(*cm) || cm->cmsg_level != SOL_SOCKET || + cm->cmsg_len > clen || cm->cmsg_len < sizeof(*cm)) { + error = EINVAL; break; + } - case SCM_RIGHTS: - oldfds = datalen / sizeof (int); - if (oldfds == 0) - break; - /* - * Check that all the FDs passed in refer to legal - * files. If not, reject the entire operation. - */ - fdp = data; - FILEDESC_SLOCK(fdesc); - for (i = 0; i < oldfds; i++, fdp++) { - fp = fget_locked(fdesc, *fdp); - if (fp == NULL) { - FILEDESC_SUNLOCK(fdesc); - error = EBADF; - goto out; - } - if (!(fp->f_ops->fo_flags & DFLAG_PASSABLE)) { - FILEDESC_SUNLOCK(fdesc); - error = EOPNOTSUPP; - goto out; - } - - } - - /* - * Now replace the integer FDs with pointers to the - * file structure and capability rights. - */ - newlen = oldfds * sizeof(fdep[0]); - *controlp = sbcreatecontrol(NULL, newlen, - SCM_RIGHTS, SOL_SOCKET); - if (*controlp == NULL) { - FILEDESC_SUNLOCK(fdesc); - error = ENOBUFS; - goto out; - } - fdp = data; - fdep = (struct filedescent **) - CMSG_DATA(mtod(*controlp, struct cmsghdr *)); - fdev = malloc(sizeof(*fdev) * oldfds, M_FILECAPS, - M_WAITOK); - for (i = 0; i < oldfds; i++, fdev++, fdp++) { - fde = &fdesc->fd_ofiles[*fdp]; - fdep[i] = fdev; - fdep[i]->fde_file = fde->fde_file; - filecaps_copy(&fde->fde_caps, - &fdep[i]->fde_caps, true); - unp_internalize_fp(fdep[i]->fde_file); - } - FILEDESC_SUNLOCK(fdesc); + cmtype = cm->cmsg_type; + if (cmtype < 0 || cmtype >= nitems(unp_internalize_ops)) { + error = EINVAL; break; - - case SCM_TIMESTAMP: - *controlp = sbcreatecontrol(NULL, sizeof(*tv), - SCM_TIMESTAMP, SOL_SOCKET); - if (*controlp == NULL) { - error = ENOBUFS; - goto out; - } - tv = (struct timeval *) - CMSG_DATA(mtod(*controlp, struct cmsghdr *)); - microtime(tv); + } + op = &unp_internalize_ops[cmtype]; + if (op->func == NULL) { + error = EINVAL; break; + } - case SCM_BINTIME: - *controlp = sbcreatecontrol(NULL, sizeof(*bt), - SCM_BINTIME, SOL_SOCKET); - if (*controlp == NULL) { - error = ENOBUFS; - goto out; - } - bt = (struct bintime *) - CMSG_DATA(mtod(*controlp, struct cmsghdr *)); - bintime(bt); - break; + odata = CMSG_DATA(cm); + odatalen = (caddr_t)cm + cm->cmsg_len - (caddr_t)odata; - case SCM_REALTIME: - *controlp = sbcreatecontrol(NULL, sizeof(*ts), - SCM_REALTIME, SOL_SOCKET); - if (*controlp == NULL) { - error = ENOBUFS; - goto out; - } - ts = (struct timespec *) - CMSG_DATA(mtod(*controlp, struct cmsghdr *)); - nanotime(ts); - break; + ix.ix_odata = odata; + ix.ix_odatalen = odatalen; - case SCM_MONOTONIC: - *controlp = sbcreatecontrol(NULL, sizeof(*ts), - SCM_MONOTONIC, SOL_SOCKET); - if (*controlp == NULL) { + /* + * If transform function gives us a fixed data + * size, allocate new mbuf here, else leave it + * to the function. + */ + if ((size = op->size) != 0) { + m = sbcreatecontrol(NULL, size, cmtype, SOL_SOCKET); + if (m == NULL) { error = ENOBUFS; - goto out; + break; } - ts = (struct timespec *) - CMSG_DATA(mtod(*controlp, struct cmsghdr *)); - nanouptime(ts); - break; - - default: - error = EINVAL; - goto out; + ix.ix_mbuf = m; + ix.ix_ndata = CMSG_DATA(mtod(m, struct cmsghdr *)); + ix.ix_ndatalen = size; + } else { + ix.ix_mbuf = NULL; + ix.ix_ndata = NULL; + ix.ix_ndatalen = 0; } - controlp = &(*controlp)->m_next; - if (CMSG_SPACE(datalen) < clen) { - clen -= CMSG_SPACE(datalen); - cm = (struct cmsghdr *) - ((caddr_t)cm + CMSG_SPACE(datalen)); - } else { - clen = 0; - cm = NULL; + /* + * Apply transform and append new mbuf (if any) to + * new control chain, even on error, so that it + * will get freed. + */ + error = (*op->func)(&ix); + if ((m = ix.ix_mbuf) != NULL) { + *controlp = m; + controlp = &m->m_next; } + + /* Advance to next message. */ + size = CMSG_SPACE(odatalen); + if (size >= clen) + break; + cm = (struct cmsghdr *)((caddr_t)cm + size); + clen -= size; } -out: m_freem(control); return (error); } +/* + * Internalize file descriptors ("rights"). + */ +static int +unp_internalize_fds(struct internalize_transform_data *ix) +{ + struct proc *p = ix->ix_td->td_proc; + struct filedesc *fdesc = p->p_fd; + struct filedescent *fde, **fdep, *fdev; + struct file *fp; + struct mbuf *m; + int i, *fdp; + int oldfds; + u_int newlen; + + KASSERT(ix->ix_ndatalen == 0, ("%s: datalen", __func__)); + + /* Round down: this is forgiving, if slightly wrong. */ + oldfds = ix->ix_odatalen / sizeof (int); + if (oldfds == 0) + return (0); + + /* + * Check that all the FDs passed in refer to legal + * files. If not, reject the entire operation. + */ + fdp = ix->ix_odata; + FILEDESC_SLOCK(fdesc); + for (i = 0; i < oldfds; i++, fdp++) { + fp = fget_locked(fdesc, *fdp); + if (fp == NULL) { + FILEDESC_SUNLOCK(fdesc); + return (EBADF); + } + if (!(fp->f_ops->fo_flags & DFLAG_PASSABLE)) { + FILEDESC_SUNLOCK(fdesc); + return (EOPNOTSUPP); + } + + } + + /* + * Now replace the integer FDs with pointers to the + * file structure and capability rights. + */ + newlen = oldfds * sizeof(fdep[0]); + m = sbcreatecontrol(NULL, newlen, SCM_RIGHTS, SOL_SOCKET); + if (m == NULL) { + FILEDESC_SUNLOCK(fdesc); + return (ENOBUFS); + } + + fdp = ix->ix_odata; + fdep = (struct filedescent **)CMSG_DATA(mtod(m, struct cmsghdr *)); + fdev = malloc(sizeof(*fdev) * oldfds, M_FILECAPS, M_WAITOK); + for (i = 0; i < oldfds; i++, fdev++, fdp++) { + fde = &fdesc->fd_ofiles[*fdp]; + fdep[i] = fdev; + fdep[i]->fde_file = fde->fde_file; + filecaps_copy(&fde->fde_caps, &fdep[i]->fde_caps, true); + unp_internalize_fp(fdep[i]->fde_file); + } + FILEDESC_SUNLOCK(fdesc); + + ix->ix_mbuf = m; + return (0); +} + +static int +unp_internalize_creds(struct internalize_transform_data *ix) +{ + struct cmsgcred *cmcred; + int i, ngroups; + struct thread *td = ix->ix_td; + struct ucred *cr = td->td_ucred; + + KASSERT(ix->ix_ndatalen == sizeof(*cmcred), ("%s: datalen", __func__)); + cmcred = ix->ix_ndata; + cmcred->cmcred_pid = td->td_proc->p_pid; + cmcred->cmcred_uid = cr->cr_ruid; + cmcred->cmcred_gid = cr->cr_rgid; + cmcred->cmcred_euid = cr->cr_uid; + ngroups = MIN(cr->cr_ngroups, CMGROUP_MAX); + cmcred->cmcred_ngroups = ngroups; + for (i = 0; i < ngroups; i++) + cmcred->cmcred_groups[i] = cr->cr_groups[i]; + return (0); +} + +static int +unp_internalize_timestamp(struct internalize_transform_data *ix) +{ + struct timeval *tv; + + KASSERT(ix->ix_ndatalen == sizeof(*tv), ("%s: datalen", __func__)); + tv = ix->ix_ndata; + microtime(tv); + return (0); +} + +static int +unp_internalize_bintime(struct internalize_transform_data *ix) +{ + struct bintime *bt; + + KASSERT(ix->ix_ndatalen == sizeof(*bt), ("%s: datalen", __func__)); + bt = ix->ix_ndata; + bintime(bt); + return (0); +} + +static int +unp_internalize_realtime(struct internalize_transform_data *ix) +{ + struct timespec *ts; + + KASSERT(ix->ix_ndatalen == sizeof(*ts), ("%s: datalen", __func__)); + ts = ix->ix_ndata; + nanotime(ts); + return (0); +} + +static int +unp_internalize_monotonic(struct internalize_transform_data *ix) +{ + struct timespec *ts; + + KASSERT(ix->ix_ndatalen == sizeof(*ts), ("%s: datalen", __func__)); + ts = ix->ix_ndata; + nanouptime(ts); + return (0); +} + static int unp_addsockcred(struct mbuf **pcontrol, struct thread *td) { --=-=-=-- From owner-freebsd-hackers@freebsd.org Fri Jul 20 06:59:37 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 27F1410341FE for ; Fri, 20 Jul 2018 06:59:37 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 92B1E705AF; Fri, 20 Jul 2018 06:59:36 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yv.noip.me (c-24-4-131-132.hsd1.ca.comcast.net [24.4.131.132]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id w6K6xSVl063762 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 19 Jul 2018 23:59:28 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-24-4-131-132.hsd1.ca.comcast.net [24.4.131.132] claimed to be yv.noip.me Subject: Re: Firefox 63 vs. sendmsg() To: Jan Beich , Don Lewis Cc: freebsd-hackers@freebsd.org, =?UTF-8?Q?Jan_Kokem=c3=bcller?= References: <844b824e-4463-82f4-a01d-5d398c4351e4@gmail.com> <7elq-l8iq-wny@FreeBSD.org> From: Yuri Message-ID: Date: Thu, 19 Jul 2018 23:59:27 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <7elq-l8iq-wny@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 06:59:37 -0000 On 07/19/18 23:35, Jan Beich wrote: > Can you attach the rebased version to bug 181741? I think, we may want > to ask a few Chromium users to check if it has an impact on bug 212812. Bug 212812 is a cross-OS bug. It also exists on Windows and Linux. It is unlikely that any FreeBSD fix will cure the Chrome problem. Yuri From owner-freebsd-hackers@freebsd.org Sat Jul 21 17:16:08 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EC44110510B9 for ; Sat, 21 Jul 2018 17:16:07 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 85F1D70A72 for ; Sat, 21 Jul 2018 17:16:07 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: by mailman.ysv.freebsd.org (Postfix) id 44CAA10510B0; Sat, 21 Jul 2018 17:16:07 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D99E10510AE for ; Sat, 21 Jul 2018 17:16:07 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A82BF70A6D; Sat, 21 Jul 2018 17:16:06 +0000 (UTC) (envelope-from Alexander@leidinger.net) Date: Sat, 21 Jul 2018 19:15:53 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1532193365; bh=0fOWk5laP1+p7fUEhKvLGxrEMgsRADb0ZmRnlFi/i5k=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=ctJC9n1sN5FK6iioL8A6ki16osEKzoPHv7mNIndYfRYl8GkkV0LnvVddKEhMLBA3J 0Jjjp+n7HEodtep18WyFPgTUsnOz7XARw8XjpNECANQsf421kBiqNUwUbEXdz9X7uf lIO3gP+xPSCWylyaene7iBeflqy1Zt7vzP9oe2GvL5YZEvaOWv0fKO/pHvngxf9/Ne 4B06qa9P81a2atWStg80+rbhkDyDiK5hqAur2oYWmiAkNhoSKVBuPfQ2ps1UPri4f8 6blTKNJQRCzyBWxj8u2zY2NvnzH/h1sPKer3XelcYsC7WhxSfSxZzYNzQ7T1lWkhrv l7nnC3dqFRrjQ== Message-ID: <20180721191553.Horde.rdWCQWOsM1XETkWQIJ4mWUc@webmail.leidinger.net> From: Alexander Leidinger To: Mark Johnston , John Baldwin Cc: hackers@freebsd.org Subject: Re: crashinfo doesn't support compressed crashdumps - which way forward? References: <20180712141409.Horde.NVSzLsvqE-2PCSDqhhfb0Xd@webmail.leidinger.net> <20180712143118.GA15892@raichu> <6858738d-7eef-cc0f-10bd-900fb822fecd@FreeBSD.org> <20180712183557.GD15892@raichu> In-Reply-To: <20180712183557.GD15892@raichu> User-Agent: Horde Application Framework 5 Content-Type: multipart/signed; boundary="=_cRPOi6cJG8JUTZkp4QLMTYY"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Mailman-Approved-At: Sat, 21 Jul 2018 17:55:37 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2018 17:16:08 -0000 This message is in MIME format and has been PGP signed. --=_cRPOi6cJG8JUTZkp4QLMTYY Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Mark Johnston (from Thu, 12 Jul 2018=20=20 14:35:57=20-0400): > On Thu, Jul 12, 2018 at 09:09:02AM -0700, John Baldwin wrote: >> Yes, here's the patch for 2 which has been tested. 4) is pretty hard >> to do in practice as you have to basically decompress into RAM when >> reading the core to do anything useful as opposed to a format that >> only compressed certain parts (e.g. if the page tables were not >> compressed only the payload in a minidump, and if it were compressed >> on some kind of block boundaries so that you could locate a given >> block and decompress it when reading specific data). Coming up with >> such a format would be more useful but requires more work. > > That patch looks ok to me, FWIW. As I pointed out, it's easy enough to > just disable crashinfo if one doesn't want the extraction to take place. Hi John, what about committing this patch? If you are too busy, do you mind if I commit it? Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_cRPOi6cJG8JUTZkp4QLMTYY Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJbU2pJAAoJEKrxQhqFIICEoyoP/3XaWKCQbPTrNhsiapP51ko9 Gm2n43MshkHRBeY7pgCw1BdOyCC0pU3c3wbMtRpcWChHoM4RqpHyGePFmINQ5OPI sNINzKqc8y4srWJEYFynGP4FdWI4+eVU2Zmv6MeWMVwS1vApWGhuNnjYlV2/Wzfh Kj1E9ERbDhhaERuFMUO/gryagmtQkpNegj2lzSv+ApO1QC2rOsHLc4bGa6ueiyXx U46piPgjwzQzCnjp44qJFeX3rqGc95sZjAN8ZzXGqGvLjJAqcSAQKSOTtHsM+zk+ QiTt2bctvBtETO/VsWAYozQ1aURbX2cgyE635o7OPl06ccMRf73tgMw2AS4EeHm7 gZxQDCKmhlUeJd56oAYSwvDpSB34uHikr6brnNBQaoh60ROO3Un+Xvsn8tMg6ZYq fdMHOvg7gQ/gwtWOOKmwwrX0vDYedcet9WOaVm8U1aXKcEII8FH3mUGimmnNYptg h0dPo2EESQCh3uwzsu3s2+SWDraZI3I0mJP2PSkT9FFqMCfMfH37dnzHtv9V12jJ 6p0whFF8W/p1hdC/dRT0a7PSCD6QU4V6IQghxiVvlwmUBy7VIljIM+2Naz2aEXf5 CDX6degfGQ1M8QRx9Q5AFpQu2xVNqiavzF/NMBFBFQctYTTSzcUD1ZuFOjz7FjOt 9GQplckD364x4bcCNKFT =CaK/ -----END PGP SIGNATURE----- --=_cRPOi6cJG8JUTZkp4QLMTYY--