From owner-freebsd-hackers@freebsd.org Mon Aug 31 12:02:27 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DEF153BFAA0 for ; Mon, 31 Aug 2020 12:02:27 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (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 4Bg82p503wz4QsJ for ; Mon, 31 Aug 2020 12:02:26 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id 07VC2Id4073677 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 31 Aug 2020 14:02:18 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1598875338; bh=m/cybf079IgifccqgeEPIB7ITWTHPBs7X6ayAB7jWHI=; h=Date:From:To:Subject; b=rgH9731LAW855+U655miJhpJoDSn8GfpPr9lgQu1DmRAO+m9PJA2quoeZ6uwUe5NK 2hu9GgrsUAWw9Xl4ItwCZqHNivz3cGMRcrbsXwFI/2+bQoZDqJK6nP2WoBD2thaL8b 253b3FhuRqedAQXschDVaBRuLhbIsPFe5cjak1pg= Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.16.1/8.15.2/Submit) with ESMTP id 07VC2Hv0073673 for ; Mon, 31 Aug 2020 14:02:18 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Date: Mon, 31 Aug 2020 14:02:17 +0200 (CEST) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: SCSI command expert needed :) Message-ID: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Rspamd-Queue-Id: 4Bg82p503wz4QsJ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=fail (headers rsa verify failed) header.d=puchar.net header.s=default header.b=rgH9731L; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-0.29 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.71)[-0.708]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.37)[-0.370]; DMARC_NA(0.00)[puchar.net]; R_DKIM_REJECT(1.00)[puchar.net:s=default]; DKIM_TRACE(0.00)[puchar.net:-]; NEURAL_SPAM_SHORT(0.09)[0.091]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 12:02:27 -0000 i already got help from this list (thank you again) as i am implementing USB-CD emulating functionality on microcontroler hardware with USB connection. Actually - i already implemented it. Works with FreeBSD Works with windows XP,7,8,10 Works with linux Doesn't work with Mac OS X. To make thing more fun - i attached REAL USB DVD recorder to Mac OS X and doesn't work too. To be exact - message window "CD is unreadable" appears. But i DO NEED my product to work with Mac OS X. I already have some ideas where is a problem but if someone could help - please mail me. From owner-freebsd-hackers@freebsd.org Tue Sep 1 00:36:20 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 92E003D2ED7 for ; Tue, 1 Sep 2020 00:36:20 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (midget.dons.net.au [IPv6:2403:5800:5101:0:ea:1cff:fefa:f00]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "dons.net.au", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BgSmd5H1Zz4LVk for ; Tue, 1 Sep 2020 00:36:16 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.15.2/8.15.2) with ESMTPS id 0810ZtHj011874 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 1 Sep 2020 10:06:00 +0930 (ACST) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.2/8.15.2/Submit) id 0810ZPe5011159 for ; Tue, 1 Sep 2020 10:05:25 +0930 (ACST) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-be813b1f1da6d6b27d681222cb70cc4f5b642383: 2001:44b8:1d2:8900:84cb:cb7e:d1b:e766 Received: from [IPv6:2001:44b8:1d2:8900:84cb:cb7e:d1b:e766] ([IPv6:2001:44b8:1d2:8900:84cb:cb7e:d1b:e766] [2001:44b8:1d2:8900:84cb:cb7e:d1b:e766]) by midget.dons.net.au (envelope-sender ) (MIMEDefang) with ESMTP id 0810ZJcD011078; Tue, 01 Sep 2020 10:05:25 +0930 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: SCSI command expert needed :) From: "O'Connor, Daniel" In-Reply-To: Date: Tue, 1 Sep 2020 10:05:19 +0930 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Wojciech Puchar X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Spam-Score: 0.2 () No, score=0.2 required=5.0 tests=HELO_MISC_IP, HELO_NO_DOMAIN, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.2 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 4BgSmd5H1Zz4LVk X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.53 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.995]; R_DKIM_ALLOW(-0.20)[dons.net.au:s=default]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.005]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[dons.net.au:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[dons.net.au,quarantine]; NEURAL_HAM_SHORT(-1.03)[-1.032]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:4764, ipnet:2403:5800:5000::/36, country:AU]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 00:36:20 -0000 > On 31 Aug 2020, at 21:32, Wojciech Puchar wrote: > Doesn't work with Mac OS X. >=20 > To make thing more fun - i attached REAL USB DVD recorder to Mac OS X = and doesn't work too. >=20 > To be exact - message window "CD is unreadable" appears. >=20 > But i DO NEED my product to work with Mac OS X. >=20 > I already have some ideas where is a problem but if someone could help = - please mail me. FWIW I have connected a USB DVD recorder to a Mac and both burnt and = read DVDs so I know it definitely works. The fact it can't read the CD suggests that perhaps the emulated file = system on it is not valid. PS I am not sure how much MacOS help you'll get on a FreeBSD mailing = list.. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From owner-freebsd-hackers@freebsd.org Tue Sep 1 11:39:34 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C914B3C36B0 for ; Tue, 1 Sep 2020 11:39:34 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (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 4BglTx50GCz4Mwb for ; Tue, 1 Sep 2020 11:39:33 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 081BdDqg076682 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 1 Sep 2020 13:39:13 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1598960353; bh=Wg1h18cgFTikIjVWJp6o83FT9YgtMfKhuiS086UZcAQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=mzcfFbahn7ZS97bZPywna/taXUErzxdt1QzJyaa6rgwj2yQjwvTTNexreohupQJrB 1Pv2WnKZEiqzPHYgQkTlhKDwWYXFvl36nsHzEEVBgF2/L/Ic1wmoGkkkjRx1xQIg3D low36Mq895WiZFYjizE5WLboAja2TMgyorwWFaMo= Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.16.1/8.16.1/Submit) with ESMTP id 081BdChp076669; Tue, 1 Sep 2020 13:39:13 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Date: Tue, 1 Sep 2020 13:39:12 +0200 (CEST) From: Wojciech Puchar To: "O'Connor, Daniel" cc: Wojciech Puchar , freebsd-hackers@freebsd.org Subject: Re: SCSI command expert needed :) In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4BglTx50GCz4Mwb X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=fail (headers rsa verify failed) header.d=puchar.net header.s=default header.b=mzcfFbah; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-0.74 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.945]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_REJECT(1.00)[puchar.net:s=default]; DMARC_NA(0.00)[puchar.net]; NEURAL_SPAM_SHORT(0.54)[0.537]; NEURAL_HAM_LONG(-1.03)[-1.035]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[puchar.net:-]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 11:39:34 -0000 i definitely don't need mac os help On Tue, 1 Sep 2020, O'Connor, Daniel via freebsd-hackers wrote: > > >> On 31 Aug 2020, at 21:32, Wojciech Puchar wrote: >> Doesn't work with Mac OS X. >> >> To make thing more fun - i attached REAL USB DVD recorder to Mac OS X and doesn't work too. >> >> To be exact - message window "CD is unreadable" appears. >> >> But i DO NEED my product to work with Mac OS X. >> >> I already have some ideas where is a problem but if someone could help - please mail me. > > FWIW I have connected a USB DVD recorder to a Mac and both burnt and read DVDs so I know it definitely works. > > The fact it can't read the CD suggests that perhaps the emulated file system on it is not valid. > > PS I am not sure how much MacOS help you'll get on a FreeBSD mailing list.. > > -- > Daniel O'Connor > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@freebsd.org Tue Sep 1 11:46:01 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8FA4E3C3839 for ; Tue, 1 Sep 2020 11:46:01 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BgldN5jqGz4NW5 for ; Tue, 1 Sep 2020 11:46:00 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id B5B8F2600E7; Tue, 1 Sep 2020 13:45:56 +0200 (CEST) Subject: Re: SCSI command expert needed :) To: Wojciech Puchar , "O'Connor, Daniel" Cc: freebsd-hackers@freebsd.org References: From: Hans Petter Selasky Message-ID: Date: Tue, 1 Sep 2020 13:45:28 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BgldN5jqGz4NW5 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-1.82 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; ARC_NA(0.00)[]; NEURAL_SPAM_SHORT(0.53)[0.528]; NEURAL_HAM_LONG(-1.04)[-1.043]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.009]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 11:46:01 -0000 On 2020-09-01 13:39, Wojciech Puchar wrote: > i definitely don't need mac os help > Maybe you'll find some USB traces for USB CD's under MacOS on the internet. Probably it expects some magic value in some of the SCSI reports. --HPS From owner-freebsd-hackers@freebsd.org Tue Sep 1 08:47:04 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E58073BE07B; Tue, 1 Sep 2020 08:47:04 +0000 (UTC) (envelope-from owner-freebsd-quarterly-calls@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4Bggfw51rcz4B1j; Tue, 1 Sep 2020 08:47:04 +0000 (UTC) (envelope-from owner-freebsd-quarterly-calls@freebsd.org) Delivered-To: freebsd-quarterly-calls@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8EFA63BDFA2; Tue, 1 Sep 2020 08:43:58 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BggbL39X4z49M3; Tue, 1 Sep 2020 08:43:58 +0000 (UTC) (envelope-from debdrup@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1598949838; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc; bh=GsZkOQ98mtEG+Y4D3fU55qcSdX0+pLRfjUgDx/1c48s=; b=Wab1TIgKdWuFPLzpjXDUyakTczIzIzOV+ciVHai/8P6GVmyQy+tevCBwALJoCRM8EoFV3o BbTEN8x+ycOF0GS09onOyoYT2Myna9Ik20Bvtw+N1YrdY8xeDUHyRfgptc3MSxNu75wBV8 WK3ifjyk6KZeVx6RIRKsSN3RgizUc69Ot0qpfF0PnGrJVJrSTRaEc4yVkyUyhtcFPrXjfq aRKBREXPOB62ytIVVlZGGDQ3NixO2KSoFWq1qRwWlvbrSCslhvVDox4UBwW2+v7BttNdMG /80vTM04VhLyTZ0VySRewDhl0IvzhXryhCMmUvcSxkQvQV5FN+XnGDXM45aSWA== Received: by freefall.freebsd.org (Postfix, from userid 1471) id 5E222B2C; Tue, 1 Sep 2020 08:43:58 +0000 (UTC) To: freebsd-quarterly-calls@FreeBSD.org Subject: Call for 2020Q3 quarterly status reports Message-Id: <20200901084358.5E222B2C@freefall.freebsd.org> Date: Tue, 1 Sep 2020 08:43:58 +0000 (UTC) From: Daniel Ebdrup Jensen ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1598949838; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc; bh=GsZkOQ98mtEG+Y4D3fU55qcSdX0+pLRfjUgDx/1c48s=; b=mgHHesVDdadDcqKAxfYLLchCwhnWCoreHZVr0W55GmMjlgoEtKNNU+tQ0tArggBQH8Eu/I X4IDSJsAgYLiXhpiHKKSd5A/FX5BbjqerX7VL0xkell4Zfx3z/sesEN637ivh5+B6rSLqp TqxjKaVgCiPgqC5tO5+ahu2VFryZ8BRKG6Trjx1S7by9e8NMZwDybXhqcQdc/PLVDYI/4f /MLhKrYgbPrF/tTQ0QV/pPLgtkzb+8YGz4L3w5aCuxAXIrZ1lMSxI4JSaQJ9FsJwsYE5fB OVpbUwhaJ/sNGvEyoWFAvzbN5qcI8aJSAhKiFoaSh/PEunuzmjyXeZxlBqCK4w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1598949838; a=rsa-sha256; cv=none; b=HbAWaampaJIiORFa2QXvUQOCiInn2118hfjPTmIgqPASNrfPuQHpLvyFLyNAdluoomDZr2 9fJ7csuyBNdyha6TOpz6KKh2Vpugfd449TWyImN8D6z+hXrmlHw62xqZQTFZZmJfYkAJy5 eyc7NRWKQfb2rx8Sa+20cPzUCpFyvN1kXM8JBi4fVmsnMSBSte80MpQ0kIMIVbdw/t2gCF vn8sk+plXdZhiYjzk2UrfHWv88m32DWGXzJo+BoLgjCDsVCNzEeLMzvRCq1l7t/NTFud1+ gaU2/LuVxJ4s82ZD66/gC4idbs3LEiHX6cqgZIlBcShlsDz1ZpoyC+oOOdF82w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-Mailman-Approved-At: Tue, 01 Sep 2020 08:47:02 +0000 X-BeenThere: freebsd-quarterly-calls@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: owner-freebsd-quarterly-calls@freebsd.org Sender: owner-freebsd-quarterly-calls@freebsd.org X-Mailman-Approved-At: Tue, 01 Sep 2020 13:03:39 +0000 X-BeenThere: freebsd-hackers@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 08:47:05 -0000 Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is October, 1st 2020 for work done since the last round of Quarterly Reports: July 2020 - September 2020. I would like to remind you that reports are collected during the last month of every quarter. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and they provide a great way to inform FreeBSD users and developers about work that is underway or has been completed. Report submissions are not limited to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred method is to follow the guidelines at the Quarterly GitHub repository: https://github.com/freebsd/freebsd-quarterly Alternatively you can fetch the Markdown template, fill it in, and email it to quarterly-submissions@FreeBSD.org. The template can be found at: https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.md We look forward to seeing your 2020Q3 reports! Thanks, Daniel Ebdrup Jensen (on behalf of quarterly@) _______________________________________________ freebsd-quarterly-calls@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-quarterly-calls To unsubscribe, send any mail to "freebsd-quarterly-calls-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Tue Sep 1 16:42:58 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A1A323CEE9D for ; Tue, 1 Sep 2020 16:42:58 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (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 4BgtD14qCxz3ZvY for ; Tue, 1 Sep 2020 16:42:57 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 081GgWSa050079 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 1 Sep 2020 18:42:32 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1598978552; bh=2voGbLGiXN00RNlNrKiWxrIvvJl2EbhsU+GTdfpBMyE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=A+KRG6HBdbeR/MhfMg9TB1C8txCSvYJitWhm8xJ/ctmmHwIby9dS4BA0bqpSOgGZp 9k2pXZ3Cz7SRPm59ip1yMbaQ15bIGU5RnclXkuvrmT7yf8aaAphXV+Un/y0nrdha36 LZG86IoxeiSYB7nrwdrDhXjn7kEO3XZFVWS/7qAU= Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.16.1/8.16.1/Submit) with ESMTP id 081GgUCd050073; Tue, 1 Sep 2020 18:42:30 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Date: Tue, 1 Sep 2020 18:42:30 +0200 (CEST) From: Wojciech Puchar To: Hans Petter Selasky cc: Wojciech Puchar , "O'Connor, Daniel" , freebsd-hackers@freebsd.org Subject: Re: SCSI command expert needed :) In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4BgtD14qCxz3ZvY X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=fail (headers rsa verify failed) header.d=puchar.net header.s=default header.b=A+KRG6HB; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-1.22 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.92)[-0.918]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_DKIM_REJECT(1.00)[puchar.net:s=default]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[puchar.net]; NEURAL_HAM_LONG(-1.03)[-1.034]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.03)[0.028]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[puchar.net:-]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 16:42:58 -0000 i now have external USB drive and CD disk that works with Mac OS X under virtualbox. usbdump and my program that will convert it to SCSI trace will be enough. tomorrow. Thank you very much for help. Already with your help i made everything working on microcontroller side as i wanted - emulation of USB CD drive + few "vendor specific" (>=0xC0) SCSI commands for my needs. Tiny, fast and no messy ready to use libraries. As it's quite off topic i propose to close that topic. But i asked freebsd-hackers for simple reason to get help from people knowing USB and SCSI specifics. And got it. Thank you very much. From owner-freebsd-hackers@freebsd.org Wed Sep 2 09:43:52 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4765B3D2810; Wed, 2 Sep 2020 09:43:52 +0000 (UTC) (envelope-from rajfbsd@gmail.com) Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BhJsz2JXQz4WG9; Wed, 2 Sep 2020 09:43:51 +0000 (UTC) (envelope-from rajfbsd@gmail.com) Received: by mail-oi1-x242.google.com with SMTP id y6so3850458oie.5; Wed, 02 Sep 2020 02:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CXP6M2e9nMepjz/nQtdC62+uoPYITJvLzcX3ke47eEU=; b=q4bOXUFY5BuHszYdz2+L2d1fRT8eAWqcqfm/PApqQFvmAuVaIlUalVKPfPeLOKSF3X X2zc5Apy/FvaKOmqbzxD+HezruEZAVP3/twNVsZlTuWfDDcC62nURN0SIHlCtn8q6wt2 CF45RbQVkGk6qdJ7r/5oEsRwMlIX8b04tvYlCGqmBcHHUremsJU7UrutbEZiLCzFgWQb Y7PPQIzdN7pTZKQVkLUFTk+fETI3TTujeGFB+p8NvA2iy7zECF81C4Fu1zC9IS/X/+k1 ZhelUDRY34sjUHywhFeti4XQ9FeE6INXwWzjoyQSyb9SyPlg3TwIm/lq+h9vkHyB+nlg yeOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CXP6M2e9nMepjz/nQtdC62+uoPYITJvLzcX3ke47eEU=; b=qgnvtlG94h85qlwME8uBYQngwCn43U/lEcqrgdkQYXUdKNXxj1NQTqBOy0/Vi6hJGN ip2n9so6YdNe1RxvqfSnR7XyqxNptK4oX+6Hj654ThjLc9h1fcf0hpN0Xyyct2G1M4/1 1APqBgYV00WR9OHtw58nkEmdZ1ooyLqHCT+SdjvawtvbPe7LS20Gm85mnZvX/DbsDNjo YshsI8Z2kje9P8NoSHCJlkS+o+hPsgBdB+fqx6Lu+JYdJzhf8RX/bmXA3B72WczGoTv4 41KI+DbkdGd6l/O5XcNKwcuEOjL2846fATYpebn+Y9c5cCtOID8KU6Z5o3H8tviVTnB9 GnLg== X-Gm-Message-State: AOAM532ldixMLh/ylWN0M7/X7G9DaUVA8Wcnzncg4gQv/iYBr5UBX2jf 3cxXP6714j5eOBc5Z3Hbcn5DE/Dx5BE4AEFd5RoZwoij X-Google-Smtp-Source: ABdhPJw3myAWYhREsXYC6rq0gw45yDpAYTa6Z7XrMgjKiWhzrIAJLy4Z7u4LeX4uq7ZK2oA9ZjjnJeT3Wt74FuQcpnM= X-Received: by 2002:aca:49ca:: with SMTP id w193mr1552808oia.46.1599039829785; Wed, 02 Sep 2020 02:43:49 -0700 (PDT) MIME-Version: 1.0 References: <7cfc7c52-b548-19bd-343b-899aca45c654@selasky.org> In-Reply-To: From: Rajesh Kumar Date: Wed, 2 Sep 2020 15:13:39 +0530 Message-ID: Subject: Re: Network throughput not reaching line rate. Need clarification on iflib. To: Daniel Ebdrup Jensen Cc: freebsd-drivers@freebsd.org, FreeBSD Hackers X-Rspamd-Queue-Id: 4BhJsz2JXQz4WG9 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=q4bOXUFY; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rajfbsd@gmail.com designates 2607:f8b0:4864:20::242 as permitted sender) smtp.mailfrom=rajfbsd@gmail.com X-Spamd-Result: default: False [-3.09 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.03)[-1.034]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.04)[-1.035]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::242:from]; NEURAL_HAM_SHORT(-0.02)[-0.018]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-drivers,freebsd-hackers]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2020 09:43:52 -0000 Hi Guys, Apologies for posting a question on an old thread. I started this thread early this year and it happened to pause working on this topic due to COVID lockdown. I recently resumed working on this and hence posting my questions on the same thread. To restate the issue, I am observing low network throughput numbers in the Receive path (on a 10G link) and trying to improve the performance numbers. As suggested in this thread, I tried using "iperf" instead of "iperf3" and also tried multiple threads. The behavior remains the same between iperf and iperf3. With a single thread I don't see any improvement in the performance numbers. But with multiple threads, I see slight improvement on the numbers, but still not touching the line rate for a 10G link. The base issue here is that the Receive buffers are not getting refilled fast enough for the Received packets. Hence I see a lot of retries (iperf3 output showing retries) and the performance drops. I could see the CPU utilization more than 90% when running iperf/iperf3 traffic. This could be the reason why Receive buffers are not filled faster. Receive path in my driver is pretty straight forward using the iflib framework. "rxd_available" interface returns the number of newly received packets. "rxd_refill" and "rxd_flush" interfaces fills the receive descriptors with buffers from iflib and update the buffer pointer registers. "rxd_pkt_get" interface traverses through all the descriptors for a packet return the received pkt info to iflib. I don't see any unwanted lock, loops and other evident bottlenecks in this path. So, what could be the reason for higher CPU utilization? and How can I debug this? Please let me know if any details are needed. Thanks, Rajesh. On Mon, Mar 2, 2020 at 4:37 AM Rajesh Kumar wrote: > Hi Guys, > > Thanks for your time in responding. > > As you people stated, the problem here doesn't seem to be single threaded > vs multi threaded. I am experience similar behavior with "iperf". It's > mostly to do with iflib and my driver(mostly my driver). It looks like the > receiver is slow in reading the packets than the sender sending the > packets. In this case, iflib drives the packet read through the exposed > interfaces (rxd_available, rxd_pkt_get etc.,). So, how to make the > receiver side read the packet faster with iflib? Is there anything that I > should take care in my driver in this regard? > > Thanks, > Rajesh. > > > > > On Sat, Feb 29, 2020 at 3:47 AM Daniel Ebdrup Jensen > wrote: > >> On Fri, Feb 28, 2020 at 7:39 PM Bruce A. Mah wrote: >> >> > [Resending with a From: address that hopefully works better.] >> > >> > If memory serves me right, Daniel Ebdrup Jensen wrote: >> > > Yes, iperf3 will default to single-threaded packet generation, et al. >> > which >> > > favours fast cores with frequency boosting facilities. >> > > You might want to use iperf2 as that's properly multi-threaded, or you >> > can >> > > use pkt-gen out of src/tools/tools/netmap/ or ports/net/pkt-gen. >> > >> > While it's true that iperf3 is single-threaded, it should be capable of >> > saturating a 10GE link with a single TCP connection, given proper >> > command-line arguments (in particular, specifying a sufficiently large >> > socket-buffer size with the -w option). >> > >> > But based on the symptom of packet loss, I'd say the single-threaded vs. >> > multi-threaded argument might not be relevant to the problem that the OP >> > has. >> > >> > Bruce. >> > >> > > On Fri, Feb 28, 2020 at 10:35 AM Hans Petter Selasky > > >> > > wrote: >> > > >> > >> On 2020-02-28 10:03, Rajesh Kumar wrote: >> > >>> Hi FreeBSD team, >> > >>> >> > >>> I am writing a network driver using iflib framework and using >> "iperf3" >> > >> tool >> > >>> for performance testing. >> > >>> >> > >> >> > >> Is there any difference with "iperf" tool and using multiple >> threads? I >> > >> think iperf3 is single threaded ??? >> > >> >> > >> --HPS >> > >> >> > >> _______________________________________________ >> > >> freebsd-hackers@freebsd.org mailing list >> > >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> > >> To unsubscribe, send any mail to " >> > freebsd-hackers-unsubscribe@freebsd.org" >> > >> >> > > _______________________________________________ >> > > freebsd-hackers@freebsd.org mailing list >> > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> > > To unsubscribe, send any mail to " >> > freebsd-hackers-unsubscribe@freebsd.org" >> > > >> > >> >> Oh, I didn't mean to imply that that wasn't part of the issue - I'm sorry >> if I made it sound like that. >> I was just confirming what Hans was asking, and possibly using the excuse >> to mention some things in base/ports that I think are also pretty neat. :) >> >> Also no longer top-posting, which was rather ghastly of me. I apologise. >> _______________________________________________ >> freebsd-drivers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-drivers >> To unsubscribe, send any mail to "freebsd-drivers-unsubscribe@freebsd.org >> " >> > From owner-freebsd-hackers@freebsd.org Wed Sep 2 17:18:51 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D9BC83DD2E7 for ; Wed, 2 Sep 2020 17:18:51 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BhVyz0q3Vz3XYT; Wed, 2 Sep 2020 17:18:50 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qv1-xf31.google.com with SMTP id db4so2423988qvb.4; Wed, 02 Sep 2020 10:18:50 -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:mime-version :content-disposition; bh=8RsDLynQUuEcgFtNQU98KbNMBN1jRWp/xKeIs5NmWM0=; b=SfirtPNUCl8YZGQx4YW4Ek2pmmgZCVs11Mf6Vncan6mNYYBmRie4V1FCbxR8lyqHtg vEcoec0EXC1RASfJWhIlpGz4c13HjNs5ao5Oc8ElG4nhtJy8zwKkig2FhgzmSOwLPvWe hqMwJ6JBNcf3cI3aXCKIwOvZ6ykImGRGxHJeX8Er6CN1rzqgaU1sPP0uwwCKIf0mhOMq rtLZ7ohY5guzXLgXSz2OW30ngJp1gAokpyECSIH+XBtuBCSj5AL2zuCPW9eV8eY0H5ZP eCt7NQe3r77Xa860Hir7LB1k4WfZZSkdfjPjWUCo+6bk7i8TB+X/TyS10ZqD8SLjZERr b7vA== 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 :mime-version:content-disposition; bh=8RsDLynQUuEcgFtNQU98KbNMBN1jRWp/xKeIs5NmWM0=; b=c5mGQNPwqPCmfvJ2ZXEq7hMOb6KuBtvo+XwqI7b3ttBcv+n/J9lmm8ZVrXZPWH0b2b bOeH5wSk5kTB34qkLf/wN/oR13GbgKhWMlx8F+Pb+ymyaSmUTzyozzXLbI6ASYeXFham GfX+DS+LqTQyX0G4kxsIi+hnlHj+89ExfPjb0HpOK5/VzhIy64MCYKTYgKBO3TP6dC9x Sk3o6ERgtuSRpAPdqJn+vCShEoEDoJ+WGrA6ihidFd9Enxj/Sa+Ir3pnD61mUPkt+GDb ahm/A2pLlU+bOzc+dgqEEq2nRkPrWTL409VFXNRgtogPqVk9AbzLcykovDob9//5+ttx J/gA== X-Gm-Message-State: AOAM5338+axVBYcvcF8k8sPUAIEmdKW4AAXizNy9/jwdF/Vp8BPpMtLu ar6BdknkV2ZxhpteVvV4aFrz8Q8rvZq87g== X-Google-Smtp-Source: ABdhPJxCDZeIP3ZnzuaEq1Kaz7tNd5IWvzy/VSCLR2d8oLw0EPGb51Kic09DA5wnD8jjf419AFxIjA== X-Received: by 2002:a0c:e085:: with SMTP id l5mr7904847qvk.178.1599067129522; Wed, 02 Sep 2020 10:18:49 -0700 (PDT) Received: from raichu (toroon0560w-lp130-08-67-71-176-35.dsl.bell.ca. [67.71.176.35]) by smtp.gmail.com with ESMTPSA id e7sm22151qtk.17.2020.09.02.10.18.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Sep 2020 10:18:48 -0700 (PDT) Sender: Mark Johnston Date: Wed, 2 Sep 2020 13:18:46 -0400 From: Mark Johnston To: freebsd-hackers@freebsd.org Cc: kib@freebsd.org, jah@freebsd.org Subject: unix socket locking cleanups Message-ID: <20200902171846.GI95175@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4BhVyz0q3Vz3XYT X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=SfirtPNU; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::f31 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-2.40 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.08)[-1.084]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_NOT_FQDN(0.50)[]; DKIM_TRACE(0.00)[gmail.com:+]; NEURAL_HAM_SHORT(-0.61)[-0.611]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f31:from]; NEURAL_HAM_MEDIUM(-1.01)[-1.007]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2020 17:18:51 -0000 Hi, I posted a series of patches that try to simplify synchronization in the unix socket code. Most of them are bite-sized but D26299 and D26301 require some thought. The last couple of patches fix some races found by syzkaller, and an earlier version of the patch series was tested by Peter Holm. I'd appreciate any feedback. Thanks in advance. https://reviews.freebsd.org/D26294 https://reviews.freebsd.org/D26295 https://reviews.freebsd.org/D26296 https://reviews.freebsd.org/D26297 https://reviews.freebsd.org/D26298 https://reviews.freebsd.org/D26299 https://reviews.freebsd.org/D26300 https://reviews.freebsd.org/D26301 From owner-freebsd-hackers@freebsd.org Thu Sep 3 07:14:12 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3B5C13DD975 for ; Thu, 3 Sep 2020 07:14:12 +0000 (UTC) (envelope-from dsl@mcusim.org) Received: from trac.mcusim.org (trac.mcusim.org [176.58.93.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BhsVq0Tp8z41SB for ; Thu, 3 Sep 2020 07:14:10 +0000 (UTC) (envelope-from dsl@mcusim.org) Received: from ds-laptop (unknown [83.26.189.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by trac.mcusim.org (Postfix) with ESMTPSA id 657457B6F3 for ; Thu, 3 Sep 2020 09:14:03 +0200 (CEST) Date: Thu, 3 Sep 2020 09:14:01 +0200 From: Dmitry Salychev To: freebsd-hackers@freebsd.org Subject: Tracking FreeBSD-CURRENT Message-ID: <20200903071401.GA24815@ds-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Unknown/0.75.1 X-Rspamd-Queue-Id: 4BhsVq0Tp8z41SB X-Spamd-Bar: - X-Spamd-Result: default: False [-1.98 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.03)[-1.029]; MID_RHS_NOT_FQDN(0.50)[]; NEURAL_SPAM_SHORT(0.31)[0.308]; DMARC_POLICY_ALLOW(-0.50)[mcusim.org,reject]; NEURAL_HAM_MEDIUM(-0.96)[-0.961]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36236, ipnet:176.58.93.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers]; RECEIVED_SPAMHAUS_PBL(0.00)[83.26.189.68:received] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2020 07:14:12 -0000 Dear FreeBSD Hackers, I'm looking for an advice about tracking development branch on my laptop. There're several steps described in details at [1] which make it clear what to do, but I'm trying to understand do I really need to track FreeBSD-CURRENT to develop a driver, for instance, if I want to keep my current laptop running r354233 patched locally. I believe that I'm not the first person in this situation and there might be existing solutions I'm not aware of. Thanks for any help. Regards, Dmitry Salychev [1] https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html From owner-freebsd-hackers@freebsd.org Thu Sep 3 12:34:47 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0F13B3E4E49 for ; Thu, 3 Sep 2020 12:34:47 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bj0ck6Y7bz4Mm8; Thu, 3 Sep 2020 12:34:46 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MBP-WLAN.fritz.box (p200300cd5f16b900210e09d63681001b.dip0.t-ipconnect.de [IPv6:2003:cd:5f16:b900:210e:9d6:3681:1b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 1C4AC2DABA; Thu, 3 Sep 2020 12:34:46 +0000 (UTC) (envelope-from se@freebsd.org) To: Dmitry Salychev References: <20200903071401.GA24815@ds-laptop> From: Stefan Esser Cc: freebsd-hackers@freebsd.org Subject: Re: Tracking FreeBSD-CURRENT Message-ID: <6ea7df0a-f62f-d4b4-da88-cc7d96635fc4@freebsd.org> Date: Thu, 3 Sep 2020 14:34:44 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.2.1 MIME-Version: 1.0 In-Reply-To: <20200903071401.GA24815@ds-laptop> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WdBdyjfx7Rclgem7ie0PsreSYlwKj6jWr" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2020 12:34:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WdBdyjfx7Rclgem7ie0PsreSYlwKj6jWr Content-Type: multipart/mixed; boundary="f4lcwwN6ltG3OLyV2O8FER7LCrdCPCXpu"; protected-headers="v1" From: Stefan Esser To: Dmitry Salychev Cc: freebsd-hackers@freebsd.org Message-ID: <6ea7df0a-f62f-d4b4-da88-cc7d96635fc4@freebsd.org> Subject: Re: Tracking FreeBSD-CURRENT References: <20200903071401.GA24815@ds-laptop> In-Reply-To: <20200903071401.GA24815@ds-laptop> --f4lcwwN6ltG3OLyV2O8FER7LCrdCPCXpu Content-Type: multipart/mixed; boundary="------------066F23E93B711912C05255FE" Content-Language: en-US This is a multi-part message in MIME format. --------------066F23E93B711912C05255FE Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Am 03.09.20 um 09:14 schrieb Dmitry Salychev via freebsd-hackers: > Dear FreeBSD Hackers, >=20 > I'm looking for an advice about tracking development branch on my lapto= p. >=20 > There're several steps described in details at [1] which make it clear > what to do, but I'm trying to understand do I really need to track > FreeBSD-CURRENT to develop a driver, for instance, if I want to keep my= > current laptop running r354233 patched locally. Any new code must be committed to -CURRENT first, before it may be merged into the stable branches (and then will make it into a release). While working with an up-to-date -CURRENT is best, you may keep it at some revision for a few weeks or even months during your development, but may have to rebase it to the then latest -CURRENT revision before the final commit. Since -CURRENT makes no guarantees with regard to kernel interfaces and data structures, there is a small risk, that you'll have to adopt to changes between when you "froze" your -CURRENT source tree and the tree at the time of commit. Staying current is not much of a problem, though. On my system, the "svn up" of the -CURRENT source tree generally finishes in less than 10 seconds and "make buildworld" takes only a few minutes, if you enable META_MODE - and if there are any collisions you'll notice them just when the conflicting changes are fresh and it is easy to assess what needs to be done to adapt your code. > I believe that I'm not the first person in this situation and there mig= ht > be existing solutions I'm not aware of. Definitely not, and I know that some developers fork -CURRENT at some suitable point and merge from the official repository only every few weeks. This will obviously not be a good approach, if you are working with data structures that are in the process of being significantly modified, e.g. to improve the scale-ability of the filesystem or network code. Regards, STefan --------------066F23E93B711912C05255FE-- --f4lcwwN6ltG3OLyV2O8FER7LCrdCPCXpu-- --WdBdyjfx7Rclgem7ie0PsreSYlwKj6jWr Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFqEEo3HqZZwL7MgrcVMTR+u171r99UQFAl9Q4uQFAwAAAAAACgkQR+u171r99USv EQf9EE4lMfbQAmSwY/qW6axHIme5PAPwAZLnupvvQ4NGWvFxFt9XqCX63bFGH3dhdocMYNYItmdZ /inHeBKdfqsG6FZVgJMBHroIDgaji4dSE+ks0UV2GO0+6bX4Txl5OgG7j2Jh1MMrbl+sjo+7k6LX 8k8YNvTy9X80FigkH0FXh9d3T1lj85Wd4XFJE0tWyn3a4/7VHdvfCrs7UlQgCvUIN5jbK4FaAAvK dhIGWsXb0VoQzkuub6CjlbwA1SKHt6ZLki0ynkNocFHDjvPl2hAP03R8YXJtCbhmBuW1I+F7r5eo Uzib82gsrnFIv4UaK0J9/GWbHCZVVU23E8/dsvmMHg== =ti5d -----END PGP SIGNATURE----- --WdBdyjfx7Rclgem7ie0PsreSYlwKj6jWr-- From owner-freebsd-hackers@freebsd.org Thu Sep 3 13:06:20 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AADEC3E5F01 for ; Thu, 3 Sep 2020 13:06:20 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (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 4Bj1K74l9Zz4PRd for ; Thu, 3 Sep 2020 13:06:19 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 083D6BH1075622 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 3 Sep 2020 15:06:12 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1599138372; bh=jqzhBzz4id7OwpycQh+NgzAE6fFzgVhjBffjI2sd3Ao=; h=Date:From:To:Subject; b=JJCN482dvpq8kfJfp5S7izP5nQDT20yWj5B4OoSItYoAH/CXpknzfM+l6fhY3sbXf 8yCO0bdBW04brOVwCddWkm1oz28nPS8vRNkK17RBEmXafVjOpQhR81EPZ2+BPVw9jm 2VLJgRvHRLV3zi7pSnvWcGdde75sSX/5VCwwHTCU= Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.16.1/8.16.1/Submit) with ESMTP id 083D6Bon075618 for ; Thu, 3 Sep 2020 15:06:11 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Date: Thu, 3 Sep 2020 15:06:11 +0200 (CEST) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: sendin raw scsi command Message-ID: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Rspamd-Queue-Id: 4Bj1K74l9Zz4PRd X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=fail (headers rsa verify failed) header.d=puchar.net header.s=default header.b=JJCN482d; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-1.15 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.84)[-0.842]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.91)[-0.907]; DMARC_NA(0.00)[puchar.net]; R_DKIM_REJECT(1.00)[puchar.net:s=default]; DKIM_TRACE(0.00)[puchar.net:-]; NEURAL_HAM_SHORT(-0.10)[-0.100]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2020 13:06:20 -0000 i already figured how to list SCSI devices in FreeBSD and find what interest me from C language. After doing so - how can i send raw SCSI command? That's all i need. CAM layer userland interface is quite complex. Thank you in advance From owner-freebsd-hackers@freebsd.org Thu Sep 3 13:08:04 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7FAF23E5E46 for ; Thu, 3 Sep 2020 13:08:04 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bj1M74kXJz4PSs for ; Thu, 3 Sep 2020 13:08:03 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 108C02601BB; Thu, 3 Sep 2020 15:07:56 +0200 (CEST) Subject: Re: sendin raw scsi command To: Wojciech Puchar , freebsd-hackers@freebsd.org References: From: Hans Petter Selasky Message-ID: <680f6f7c-a564-9150-36b3-371be0ee8766@selasky.org> Date: Thu, 3 Sep 2020 15:07:29 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Bj1M74kXJz4PSs X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-2.82 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_LONG(-0.99)[-0.989]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.53)[-0.534]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2020 13:08:04 -0000 On 2020-09-03 15:06, Wojciech Puchar wrote: > i already figured how to list SCSI devices in FreeBSD and find what > interest me from C language. > > After doing so - how can i send raw SCSI command? > > That's all i need. > > CAM layer userland interface is quite complex. > > Thank you in advance Hi, usbtest can do this: /usr/src/tools/tools/usbtest --HPS From owner-freebsd-hackers@freebsd.org Thu Sep 3 13:34:37 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E37173E6742 for ; Thu, 3 Sep 2020 13:34:37 +0000 (UTC) (envelope-from dsl@mcusim.org) Received: from trac.mcusim.org (trac.mcusim.org [176.58.93.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bj1xn0cSzz4RKV; Thu, 3 Sep 2020 13:34:36 +0000 (UTC) (envelope-from dsl@mcusim.org) Received: from ds-laptop (unknown [83.26.189.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by trac.mcusim.org (Postfix) with ESMTPSA id B05BC7B7B7; Thu, 3 Sep 2020 15:34:34 +0200 (CEST) Date: Thu, 3 Sep 2020 15:34:32 +0200 From: Dmitry Salychev To: Stefan Esser Cc: freebsd-hackers@freebsd.org Subject: Re: Tracking FreeBSD-CURRENT Message-ID: <20200903133432.GC24815@ds-laptop> References: <20200903071401.GA24815@ds-laptop> <6ea7df0a-f62f-d4b4-da88-cc7d96635fc4@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6ea7df0a-f62f-d4b4-da88-cc7d96635fc4@freebsd.org> User-Agent: Unknown/0.75.1 X-Rspamd-Queue-Id: 4Bj1xn0cSzz4RKV X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.78 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[83.26.189.68:received]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_NOT_FQDN(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.002]; NEURAL_HAM_MEDIUM(-0.99)[-0.989]; NEURAL_HAM_SHORT(-0.49)[-0.490]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[mcusim.org,reject]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36236, ipnet:176.58.93.0/24, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2020 13:34:37 -0000 Hi Stefan, > Any new code must be committed to -CURRENT first, before it may be > merged into the stable branches (and then will make it into a release). Is this approach the same for code which is intended for ARM? For example, if there is a driver for an ethernet transceiver connected to BeagleBone Black. I should track -CURRENT on my laptop, add, build and test my driver on BBB, merge the latest changes from -CURRENT and send a patch. Am I correct? > Since -CURRENT makes no guarantees with regard to kernel interfaces > and data structures, there is a small risk, that you'll have to adopt > to changes between when you "froze" your -CURRENT source tree and the > tree at the time of commit. > > Staying current is not much of a problem, though. On my system, the > "svn up" of the -CURRENT source tree generally finishes in less than > 10 seconds and "make buildworld" takes only a few minutes, if you > enable META_MODE - and if there are any collisions you'll notice > them just when the conflicting changes are fresh and it is easy to > assess what needs to be done to adapt your code. It looks like I'd better to have a spare disk for my experiments to track -CURRENT. > Definitely not, and I know that some developers fork -CURRENT at > some suitable point and merge from the official repository only every > few weeks. > > This will obviously not be a good approach, if you are working with > data structures that are in the process of being significantly modified, > e.g. to improve the scale-ability of the filesystem or network code. It shouldn't be a problem because I'd like to program a driver for Microchip's KSZ9563R (eth switch) which I might only be interested in :) Thanks for your help! Regards, Dmitry From owner-freebsd-hackers@freebsd.org Thu Sep 3 16:54:18 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 32F753C40C3 for ; Thu, 3 Sep 2020 16:54:18 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 4Bj6N909mSz3T5T; Thu, 3 Sep 2020 16:54:16 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id ADE9C3C0199; Thu, 3 Sep 2020 16:54:15 +0000 (UTC) Date: Thu, 3 Sep 2020 16:54:15 +0000 From: Brooks Davis To: Dmitry Salychev Cc: Stefan Esser , freebsd-hackers@freebsd.org Subject: Re: Tracking FreeBSD-CURRENT Message-ID: <20200903165415.GA12762@spindle.one-eyed-alien.net> References: <20200903071401.GA24815@ds-laptop> <6ea7df0a-f62f-d4b4-da88-cc7d96635fc4@freebsd.org> <20200903133432.GC24815@ds-laptop> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline In-Reply-To: <20200903133432.GC24815@ds-laptop> User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4Bj6N909mSz3T5T X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of brooks@spindle.one-eyed-alien.net has no SPF policy when checking 199.48.129.229) smtp.mailfrom=brooks@spindle.one-eyed-alien.net X-Spamd-Result: default: False [-3.59 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; FREEFALL_USER(0.00)[brooks]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.005]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.69)[-0.689]; SIGNED_PGP(-2.00)[]; FORGED_SENDER(0.30)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; RCVD_COUNT_ZERO(0.00)[0]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:36236, ipnet:199.48.128.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2020 16:54:18 -0000 --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 03, 2020 at 03:34:32PM +0200, Dmitry Salychev via freebsd-hacke= rs wrote: > Hi Stefan, >=20 > > Any new code must be committed to -CURRENT first, before it may be > > merged into the stable branches (and then will make it into a release). >=20 > Is this approach the same for code which is intended for ARM? For > example, if there is a driver for an ethernet transceiver connected to > BeagleBone Black. I should track -CURRENT on my laptop, add, build and > test my driver on BBB, merge the latest changes from -CURRENT and send a > patch. Am I correct? If your code is destined for another system, there's little reason to track -CURRENT on your laptop. You can easily cross-build -CURRENT from (e.g.) 12.1 or an older -CURRENT. -- Brooks --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJfUR+2AAoJEKzQXbSebgfAJB0H/Ah8AQdeEVpQr2q4i6T8g17C C+IEWSQp9+sbHOMf6yWxiauh94tIx9ZAihzrPOlnUjZVJBwDldi+nkDxP/lZi6gn vfZH9v++OXnfL4MZfM1sI2gVb2Yfus2znV37/eJEd1mHFq5MtI5++CjU/5Zsrmzc T/ehOO0AgR7uSdhodfS8eQ52pDWS2BzUR0rhkNNZHXD0XVhnV5tVlfvJVlfRyxL0 tDCvAyW6xvK0rVksv3u1VM86GCOtTuvsb8YDJuDiXZkPvMtYWskrNmUokTlugf+U +je5KrQ39a8BNpsf1ZTG352bIAg2JHnAhn+rifW/mjq1vBWePZ4EKI7APS7jTAc= =xcEP -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3-- From owner-freebsd-hackers@freebsd.org Sat Sep 5 00:28:02 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5F1583D41BB for ; Sat, 5 Sep 2020 00:28:02 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f52.google.com (mail-ot1-f52.google.com [209.85.210.52]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BjwPD5pxGz4p06 for ; Sat, 5 Sep 2020 00:28:00 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f52.google.com with SMTP id u25so7471207otq.6 for ; Fri, 04 Sep 2020 17:28:00 -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:from:date:message-id:subject:to; bh=h+0M4ZYraopwvGqpjjERXEoWfW1xVhWrCSyP/tR5Pd4=; b=KkhDZ8IEerWjbrXq8kMkEsLe4mWlZeSgW7GZnoRI8Q8731k2s5UYgmWmHijvPTyGW5 PZm5rparRQuy13ZOoofRPLlSaofqY4CPVXPFjdMg1c+5ZP+YhFOl4QRtFfhyo5q6UL9P cea4t7wXe9tXrOvIlSvouCsgOfBmY5/hup1gUgZMEEx3UGIA1PJOgm/wLvlP5hoVHzkd FPfU1U5/9Yv7uOcoX7PJsuSRY2o82rfaLR9xe/7g7Hzau/1dbTbaDxRXmiTNnsmp4bQi /oqdEg1Qox4zGFxJGZvL+J4yIPMxDPl2eI2v67T+ElsZQy+hpMAyxdNt8uT84kBqX7V3 sQ8g== X-Gm-Message-State: AOAM532XwGH7x0GRP/7I4dpjs30wTOGBJs6bf8Tbff0xBIgIX2dGqOpw JalNNu9qiWYwvtQ8OdjrXtXp5W8967cWKIPpDTdhz3SZMc4= X-Google-Smtp-Source: ABdhPJyYUwa+17ErbP8Dhr7BDMhG8rc8Sfy6K54b1pVgr9DqItnDL/Am1SBGZNUIUgpLBP6u1gUeZRtpfTaUhHGLkDw= X-Received: by 2002:a05:6830:1286:: with SMTP id z6mr7111914otp.291.1599265679296; Fri, 04 Sep 2020 17:27:59 -0700 (PDT) MIME-Version: 1.0 From: Alan Somers Date: Fri, 4 Sep 2020 18:27:48 -0600 Message-ID: Subject: panic!("docallb") in nfsrv_docallback To: FreeBSD Hackers X-Rspamd-Queue-Id: 4BjwPD5pxGz4p06 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.210.52 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-2.60 / 15.00]; RWL_MAILSPIKE_GOOD(0.00)[209.85.210.52:from]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_DN_ALL(0.00)[]; SUBJECT_HAS_EXCLAIM(0.00)[]; NEURAL_HAM_SHORT(-0.78)[-0.778]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; TO_DOM_EQ_FROM_DOM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.83)[-0.830]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.996]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[209.85.210.52:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2020 00:28:02 -0000 I just saw this panic on a 12-stable machine. Unfortunately, I don't have a core dump, just a stack trace. It was serving NFS v4.0, with delegations enabled. The clients were all Debian, with Linux 3.16.0. The proximal cause of the panic seems to be that the file had a write delegation issued to an unconfirmed client. Root cause is harder to determine. Did the kernel previously issue a delegation to an unconfirmed client? Or did the client somehow change to an unconfirmed state after the delegation was issued, perhaps due to a race? It's hard to tell, but I don't see any checks for lc_flags & LCL_NEEDSCONFIRM in nfsrv_openctrl (which issues the delegations), so I'm guessing that that's the problem. If so, then the event trace would look like this: 1) Client Alice sends SETCLIENTID. The server creates a client state structure for her. _) Client Alice should've sent SETCLIENTID_CONFIRM, but doesn't. Bad Alice! 2) Client Alice sends OPEN for some file, and is issued a write delegation. The server shouldn't have issued it, because Alice's client ID is unconfirmed. Bad server! 3) Client Bob tries to do a GETATTR on that same file. 4) In nfsrv_checkgetattr, the kernel finds a write delegation for that file, owned by client Alice. 5) The kernel tries to send a NFSV4OP_CBGETATTR callback to Alice, to see if the file's attributes have changed. 6) But Alice's client ID is unconfirmed. Oh no! Panic! Does this sound plausible? Should there be a check for LCL_NEEDSCONFIRM somewhere around line 3166 in nfs_nfsdstate.c? Grateful for any help. -Alan P.S.: stack trace kdb_backtrace vpanic panic nfsrv_docallback nfsrv_checkgetattr nfsrvd_getattr nfsrvd_dorpc nfssvc_program svc_run_internal svc_thread_start fork_exit fork_trampoline From owner-freebsd-hackers@freebsd.org Sat Sep 5 02:58:54 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 128D43DA2F7 for ; Sat, 5 Sep 2020 02:58:54 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670041.outbound.protection.outlook.com [40.107.67.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BjzlK0MKWz3VB4; Sat, 5 Sep 2020 02:58:52 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=f3vUF6SvIpyvgUXr+ekGiRR+EE4HCWojDZNtCOFjUvth8guAwCMyt1B965JTELReTzeCw1K+0f6ZerLHalM4w2PYaXN5n/ErKFoibRl7O5Q/Gsiu0xuBposQ0/zItJguu6a17fKEdQNAixRZUX6K6MOTASNmTrtGI96Olymldc/J7Ab488JSO6u+rPuS+iuB6vRAJla8YlvvFpeaoPlvf8scQPGsPVmgrOGANJkhrRnoWRgKVm7OvSJIkbFXUVlP6XRYiBfewhVCnz2Lbx7ZN8I7ibKPJh1BPfwdir75fxhq1o4KppwUJumjOKjds8jZMXrbtiR9+dPkirBJ+g9ybQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=83xbzpEXJ9t39zy1cPDP3mM8r7Ne2XkZ1BQv095UHJM=; b=l0oLhH0s2CXz236RdiwI2OU7jMvz3xubBLbCkwkwLGxWaliRQzkW6zSwAGw6ce7NMdKGPPV7Cnv1qxJ5eSaKTaKfn3QTVaGnFfmO7tdwo39zPVSqNDn78oyeYkJclYejjvfaEewywy5Ofw6Jck/jO8BVxninFHKnq8x5QYF+P4spQEF5OLyztbKpAZ9YEcDengLgYeRtzhy+nRZx5kVvZwOHJh0CnXqtTyG3yNWyjdvIF0tUf2r1QwKy+FKa07UCfLotb8/3Rtty1K0Dz0VvrB3FSNCsFK6hdvdyHm7fa3i33KT4oeHDPhsQ939+hXRxaRir7o8L1Mt1S3V7XCUIWw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=83xbzpEXJ9t39zy1cPDP3mM8r7Ne2XkZ1BQv095UHJM=; b=J+DNI4BIsTjDaYtfTK4YOKOc8QMV1PwgNpyc0Fu4te6Ldw9XidLULXeZbr873PQOuQWRZ89hR95ZpAw0XDUyewFakdBOGJfnQUawx3Zznlry9oD4/Annz3c1xmpnoFr6+LceFU5pLjUeQKghInkYkV2BwiI0Bd7Q4t56ubzR8gnB1JjYRPviDdvtJt6IiwafTl7xqtSGWT4NetzrZ9m5xuChplAbs68nXesmVM5fS0gD+CzWHLded4X/8kuDfC8FLOdpcWNAhIHFYU3u0YT3YAt92L20jELNMIxC9EYEMkgBPpQKraqA9Me21k4dsVmuWOz9GLLxvGcQaWuk7zlwTA== Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:24::27) by YTOPR0101MB0713.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b00:25::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.15; Sat, 5 Sep 2020 02:58:51 +0000 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20]) by YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20%6]) with mapi id 15.20.3348.017; Sat, 5 Sep 2020 02:58:51 +0000 From: Rick Macklem To: Alan Somers , FreeBSD Hackers Subject: Re: panic!("docallb") in nfsrv_docallback Thread-Topic: panic!("docallb") in nfsrv_docallback Thread-Index: AQHWgxtspJUVGlzLXkCTJBO3gNcFCalZVDgu Date: Sat, 5 Sep 2020 02:58:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 29c26bb6-aaa4-4d06-beb7-08d851479e6f x-ms-traffictypediagnostic: YTOPR0101MB0713: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tJ8Z3gtvj3iXilZCogArUsNKiV8ENW+r8eH5gnXQ11kuOqWb+vaMVrW1gG5TuDl+tp94QWx2anygceyUeCGL1B2+Zk2I+2j39p+ZdEhhYW6mhkC5tvH0zW04t3QfNry2OLnMuLxGu0erVk4GeEMjc6sZ7SagEGW89kwN8PPv2JlNxjFPlTZjAa3qKOOE2JtfjDwlWpgfg+Y4ZNj5cOqJYHuVpoD7nPw0EEJhh0lmARLam1vB0lCVFr/hdmTQPF8MXTYMgztrqEBWwQ4ypz/tI/Rtg4sS5YVjTa/Iy24ov3ZkFsrH20QPtaMENKbXryRKCtFp1kvSPSoUS+juvjS1F14MqmRpzJBxa7s1sBMhhXWoTtfsRmWctjcxJaF8XG72kWcncfdt7Ir7/IXlxFERQg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(136003)(346002)(366004)(39860400002)(396003)(376002)(83380400001)(9686003)(55016002)(478600001)(5660300002)(786003)(316002)(186003)(33656002)(91956017)(76116006)(966005)(64756008)(8936002)(66946007)(66446008)(110136005)(8676002)(86362001)(71200400001)(66476007)(66556008)(7696005)(450100002)(2906002)(6506007)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: tXX8sb7vGajP/X6aH9uWBR5NfZh3n+8KVcs+PcFilJL9/1WyfYhBQgrXXFG2F4s7YB0YO48dci+R6Rmyw2JgJNdeQ2j8cPc93J7fkEbkyiOsgmgnH3vuJ54pkBj5LjySUIL+CgvF2R9UiYGoZ9mzBn1Xq2oyS41XO4a6ZyiaNXjP5maBETzkMvpSdFWY4nddKWiUKddPPv1HIoNpng7wloHIygjuRSaGFndF+/3i/uPI6cAenugilw3c4A1SUoUxl79oe44tF9tDLoxQmBIt4Vv/IBxuv7zNjhHrWz2En5tFLN8vlKsSDoF7TowJqrMJEZm10ruUxfRS+lUz9nWDIVESWwer2arimO1CTuG8vHbeote9S/6i/XdZzjB+batueuAPcWJaWQqv4ba9Vq4beDhEA+GmSwscThvM9w5lbI1N9nG3gcOkmHm6rCK1KT158OkO47/DV90vbMz/cs7w2d1ANtfGKoyA811MNiN1XnGkkifTx4ZyHkOgQx+tnlysfBVWktiuTTZ2mOGBnocZEF4XMi1RRFF8OT+zEQe/vE/HwK65pM4Qu2icKUh9qQt104vpZEuKgzzWNsLaL3ig4Mg59Ho2LM0vQhVZeviBpiNHE7+CcorDEQXhrO1VC/KQoWukztMyH7TTvAces+497MZF0DtwMpvhLsxRJ2uEh0oJRnLmSPJa/tnsKjkDclWf20wEgpnD2MT+KnaTfVszBQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 29c26bb6-aaa4-4d06-beb7-08d851479e6f X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Sep 2020 02:58:51.4687 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JjVOivyvYLD4EGUl2lUaFPIzz+JN/czOqfhsqEzyAx5TW/YfrKaB1XsFCyTyeWWKiclwZt4ZenZOMBCfMKBQag== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB0713 X-Rspamd-Queue-Id: 4BjzlK0MKWz3VB4 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=J+DNI4BI; dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.67.41 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-6.46 / 15.00]; NEURAL_HAM_MEDIUM(-1.04)[-1.039]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.02)[-1.020]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[40.107.67.41:from]; SUBJECT_HAS_EXCLAIM(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; NEURAL_HAM_SHORT(-1.40)[-1.405]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MAILMAN_DEST(0.00)[freebsd-hackers]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.67.41:from] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2020 02:58:54 -0000 Alan Somers wrote:=0A= >I just saw this panic on a 12-stable machine. Unfortunately, I don't have= =0A= >a core dump, just a stack trace. It was serving NFS v4.0, with delegation= s=0A= >enabled. The clients were all Debian, with Linux 3.16.0.=0A= I will generically note that I believe the Linux NFS client developers most= ly=0A= test NFSv4.1, 4.2, so if the clients support NFSv4.1, it might be worth upg= rading?=0A= =0A= Also, delegations aren't enabled by default for a couple of reasons.=0A= 1 - For a long time, Linux only knew how to use read delegations and I felt= =0A= (and still feel) they are pretty useless.=0A= 2 - They are complex to get right.=0A= 3 - Although they should reduce the number of Open operations against the= =0A= server, I haven't observed dramatic performance improvements because= =0A= of them.=0A= =0A= >The proximal cause of the panic seems to be that the file had a write=0A= >delegation issued to an unconfirmed client. Root cause is harder to=0A= >determine. Did the kernel previously issue a delegation to an unconfirmed= =0A= >client? Or did the client somehow change to an unconfirmed state after th= e=0A= >delegation was issued, perhaps due to a race?=0A= I think the first case is more likely. Since client confirmation happens im= mediately=0A= for NFSv4.1 (the ExchangeID and Createsession must occur before anything=0A= else can happen), I wouldn;t be surprised if the Linux client tries to do a= n Open=0A= before the SetClientIDConfirm has completed for NFSv4.0.=0A= =0A= >It's hard to tell, but I don't see any checks for lc_flags &=0A= >LCL_NEEDSCONFIRM in nfsrv_openctrl (which issues the delegations), so I'm= =0A= >guessing that that's the problem.=0A= The server should definitely check for a confirmed ClientID during Open and= =0A= fail any Open attempt where that is not the case.=0A= --> I'll take a look at the code. I wrote it about 20years ago, but I can p= robably=0A= figure out how it works.;-)=0A= =0A= > If so, then the event trace would look=0A= >like this:=0A= >=0A= >1) Client Alice sends SETCLIENTID. The server creates a client state=0A= >structure=0A= > for her.=0A= >_) Client Alice should've sent SETCLIENTID_CONFIRM, but doesn't. Bad Alic= e!=0A= >2) Client Alice sends OPEN for some file, and is issued a write delegation= .=0A= > The server shouldn't have issued it, because Alice's client ID is=0A= > unconfirmed. Bad server!=0A= >3) Client Bob tries to do a GETATTR on that same file.=0A= >4) In nfsrv_checkgetattr, the kernel finds a write delegation for that fil= e,=0A= > owned by client Alice.=0A= >5) The kernel tries to send a NFSV4OP_CBGETATTR callback to Alice, to see= =0A= >if the=0A= > file's attributes have changed.=0A= >6) But Alice's client ID is unconfirmed. Oh no! Panic!=0A= >=0A= >Does this sound plausible? Should there be a check for LCL_NEEDSCONFIRM= =0A= >somewhere around line 3166 in nfs_nfsdstate.c? Grateful for any help.=0A= Yes, it does. I would have thought that I'd have checked for the unconfirme= d=0A= ClientID, but maybe not.=0A= =0A= It is also possible that the client somehow did a SetClientID after the Ope= n=0A= that issued the delegation, putting it back in "unconfirmed" state.=0A= It that was the case, maybe the panic(), intended to catch corrupted data= =0A= structures, was overkill.=0A= =0A= >-Alan=0A= >=0A= >P.S.: stack trace=0A= >=0A= >kdb_backtrace=0A= >vpanic=0A= >panic=0A= >nfsrv_docallback=0A= >nfsrv_checkgetattr=0A= nfsrv_checkgetattr() should probably check for the case of an unconfirmed= =0A= clientid and then return ignoring any delegations hanging off it instead= =0A= of attempting a callback.=0A= --> This would handle the case where the client did a SetClientID after the= =0A= Open that acquired the delegation, leaving the ClientID unconfirmed.= =0A= - The two RPCs doing SetClientID and SetClientIDConfirm are normally= =0A= done only upon mounting or when the client thinks it has lost the= =0A= ClientID due to a lease expiry, but there is also the case where it= is=0A= changing the callback address. (This could explain the SetClientID= =0A= happening after the Open that acquired the delegation.)=0A= --> Hint. Can you now see why NFSv4.1 chose to do things differently?=0A= =0A= nfsrvd_getattr=0A= nfsrvd_dorpc=0A= nfssvc_program=0A= svc_run_internal=0A= svc_thread_start=0A= fork_exit=0A= fork_trampoline=0A= =0A= Thanks for reporting it. I'll take a look, rick=0A= =0A= _______________________________________________=0A= freebsd-hackers@freebsd.org mailing list=0A= https://lists.freebsd.org/mailman/listinfo/freebsd-hackers=0A= To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= =0A= =0A= From owner-freebsd-hackers@freebsd.org Sat Sep 5 03:57:59 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3C4903DD07F for ; Sat, 5 Sep 2020 03:57:59 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f52.google.com (mail-ot1-f52.google.com [209.85.210.52]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bk13V1SNxz3Z0B for ; Sat, 5 Sep 2020 03:57:57 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f52.google.com with SMTP id m12so4753273otr.0 for ; Fri, 04 Sep 2020 20:57:57 -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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XyrSBdJcPOabA+ZRMIjQMKg/LmXQXyxBzGHktzeK1RE=; b=o4axgvin/rnY2cTKTdkJ13t4pRxt8/20LWHJr3W6e2XK2x5cSoo8Fi/oVXHyujO41F sWNeiO81KhZ/l2j9XEN7/ZWVKpyWpGPytEcK5fE9NNFbgczCvwirOloA9KiZj95SkKEc mackBkIy7G/+MK1ZwsSX52N5BYdDwEVS+PBighcBrqJeUUaPOJgb4zFVMfZJEAz73+Vj wafY3OQUF2i0bXrJ9+5LxirG4jULWEz8rEFCXsJ7jU350zvayk2LettFAfFcWTlQCDSP 69mi8W9qQ6YVJ8Jo0b/2ByCsIxbb4nAjzFmGRCrK69iKfzJyi5FV9X2O0dY/vUCbvMu5 dSNw== X-Gm-Message-State: AOAM533LHbTsS/75X98tJ5kLk2Mf+OGuT1YitVKvNdj16v5ef9+uW0tz +Yf2BLM5Seza7tVzpDlYl7lmSMaC4qjTkmC3PrrIayZ5l/g= X-Google-Smtp-Source: ABdhPJxXvsNmVYbGITrvsKVrKGGW4GACgjQ0wJ5a93m/kP5fD7BDnymK9TjHI2Bpx6C7UatSLiMo4U6uXSv6khLexNg= X-Received: by 2002:a9d:758b:: with SMTP id s11mr7326536otk.251.1599278276562; Fri, 04 Sep 2020 20:57:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Fri, 4 Sep 2020 21:57:45 -0600 Message-ID: Subject: Re: panic!("docallb") in nfsrv_docallback To: Rick Macklem Cc: FreeBSD Hackers X-Rspamd-Queue-Id: 4Bk13V1SNxz3Z0B X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.210.52 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-3.39 / 15.00]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[209.85.210.52:from]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.02)[-1.024]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; SUBJECT_HAS_EXCLAIM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.210.52:from]; NEURAL_HAM_SHORT(-1.29)[-1.291]; NEURAL_HAM_MEDIUM(-1.08)[-1.077]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; MAILMAN_DEST(0.00)[freebsd-hackers] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2020 03:57:59 -0000 On Fri, Sep 4, 2020 at 8:58 PM Rick Macklem wrote: > Alan Somers wrote: > >I just saw this panic on a 12-stable machine. Unfortunately, I don't have > >a core dump, just a stack trace. It was serving NFS v4.0, with > delegations > >enabled. The clients were all Debian, with Linux 3.16.0. > I will generically note that I believe the Linux NFS client developers > mostly > test NFSv4.1, 4.2, so if the clients support NFSv4.1, it might be worth > upgrading? > > Also, delegations aren't enabled by default for a couple of reasons. > 1 - For a long time, Linux only knew how to use read delegations and I felt > (and still feel) they are pretty useless. > 2 - They are complex to get right. > 3 - Although they should reduce the number of Open operations against the > server, I haven't observed dramatic performance improvements because > of them. > > >The proximal cause of the panic seems to be that the file had a write > >delegation issued to an unconfirmed client. Root cause is harder to > >determine. Did the kernel previously issue a delegation to an unconfirmed > >client? Or did the client somehow change to an unconfirmed state after > the > >delegation was issued, perhaps due to a race? > I think the first case is more likely. Since client confirmation happens > immediately > for NFSv4.1 (the ExchangeID and Createsession must occur before anything > else can happen), I wouldn;t be surprised if the Linux client tries to do > an Open > before the SetClientIDConfirm has completed for NFSv4.0. > > >It's hard to tell, but I don't see any checks for lc_flags & > >LCL_NEEDSCONFIRM in nfsrv_openctrl (which issues the delegations), so I'm > >guessing that that's the problem. > The server should definitely check for a confirmed ClientID during Open and > fail any Open attempt where that is not the case. > --> I'll take a look at the code. I wrote it about 20years ago, but I can > probably > figure out how it works.;-) > > > If so, then the event trace would look > >like this: > > > >1) Client Alice sends SETCLIENTID. The server creates a client state > >structure > > for her. > >_) Client Alice should've sent SETCLIENTID_CONFIRM, but doesn't. Bad > Alice! > >2) Client Alice sends OPEN for some file, and is issued a write > delegation. > > The server shouldn't have issued it, because Alice's client ID is > > unconfirmed. Bad server! > >3) Client Bob tries to do a GETATTR on that same file. > >4) In nfsrv_checkgetattr, the kernel finds a write delegation for that > file, > > owned by client Alice. > >5) The kernel tries to send a NFSV4OP_CBGETATTR callback to Alice, to see > >if the > > file's attributes have changed. > >6) But Alice's client ID is unconfirmed. Oh no! Panic! > > > >Does this sound plausible? Should there be a check for LCL_NEEDSCONFIRM > >somewhere around line 3166 in nfs_nfsdstate.c? Grateful for any help. > Yes, it does. I would have thought that I'd have checked for the > unconfirmed > ClientID, but maybe not. > > It is also possible that the client somehow did a SetClientID after the > Open > that issued the delegation, putting it back in "unconfirmed" state. > It that was the case, maybe the panic(), intended to catch corrupted data > structures, was overkill. > > >-Alan > > > >P.S.: stack trace > > > >kdb_backtrace > >vpanic > >panic > >nfsrv_docallback > >nfsrv_checkgetattr > nfsrv_checkgetattr() should probably check for the case of an unconfirmed > clientid and then return ignoring any delegations hanging off it instead > of attempting a callback. > --> This would handle the case where the client did a SetClientID after the > Open that acquired the delegation, leaving the ClientID unconfirmed. > - The two RPCs doing SetClientID and SetClientIDConfirm are normally > done only upon mounting or when the client thinks it has lost the > ClientID due to a lease expiry, but there is also the case where > it is > changing the callback address. (This could explain the SetClientID > happening after the Open that acquired the delegation.) > --> Hint. Can you now see why NFSv4.1 chose to do things differently? > > nfsrvd_getattr > nfsrvd_dorpc > nfssvc_program > svc_run_internal > svc_thread_start > fork_exit > fork_trampoline > > Thanks for reporting it. I'll take a look, rick > Wow, thanks! That's better feedback than I ever hoped for. About fixing the bug: my odds of reproducing it in the original setting are low, since it's a production server. And I doubt I could force it via normal traffic to a development server, either. It took many terabytes of traffic to hit the bug this once. I think my best shot would be to use LibNFS ( https://github.com/sahlberg/libnfs) to write a custom misbehaving NFS client. But that's daunting; the only NFSv4 examples are nearly 1,000 lines each. But, I could probably do it with enough time. Do you have any better ideas? -Alan From owner-freebsd-hackers@freebsd.org Sat Sep 5 04:14:22 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 238793DDF13 for ; Sat, 5 Sep 2020 04:14:22 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660071.outbound.protection.outlook.com [40.107.66.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bk1QP0pMRz3bLD; Sat, 5 Sep 2020 04:14:20 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NG1p9gmBY5uXwnhjs5I5yzfYjH7TSkT07jjFpfeJ277wSh8d3e9PXWOMrYM1Tk2vZoULohbwdyrqUNO1xGSLA4zMIB/XHLZoO9f/aSuCgh5RDSw1iR42jRrC7FR24Jio9iZ6cA1BaasM8og8x9+INvsoh3kEqcpx4rni3sSlj/aKi7hlOX7NYgdGWVDy63pyAfK7oPnEYPOWwT0CJ1RqeZY3r9aGBFUiCeIuKU1rtH3tSG7sw0VSjjcgTmbhAH3WKvs4wXndUu8vYvANsfRcVsSwPOpSXOGpzW9aq4++v0jiBmo+pnSAToE4PuYm/Ai0Pqm8u+t6zp/KivH4Cj48aw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DpUZMDl1CiXTJawR/+JPTbalc2p1jv3a0jqgTq81Cgs=; b=adrqkd9vLO+jaKeb1PN30IhZSHq1MPpxkZI3CCOaIeOaWAZO9+SRiXgrYGtjJNPbCpldG5pr2KvJZaSR+YYehSSQ8jlI8MV/+9LXHkqixNqGud56f+K7ygveRL0b8Ma2x+Z3Etavufv33ajlYLA+n9gAiHCAiQZjE7U1Q0vytQjCQvR5MPbAM+FIJFeOyV52ZPtvvND7oDRIy4fzl1dTc5UhVE0I5xSYmgTqv0CjhECeGXR4qnYbBSRvZA98Hc0OgWO1YRx0D2wcEAHfkPxylRqePQXYIJyPkI+Ry+N99UZoze8iGBW7xYoqEPjpHXovl3z9qXuY64rFRZWUHsBXsQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DpUZMDl1CiXTJawR/+JPTbalc2p1jv3a0jqgTq81Cgs=; b=nC07dK4aDu9eLpTuQhgHfVPrfzNOUIFxTOHGiT0K87Q82QGaiE6UBHRvkKgLkkDwqXS9T6ce55ljDDRpdZIYYUoLDQ6+4AL2y4gSBHslhsmJLlH4A/rmYxyxrPrpmSn165LwAsl9y8RHYlgP7saCEAPC++FrhZ3IYAWp446kwrTpQQS9HyZRLxyZ0pZoi6aJW+aFBykuIHh6diFWeQIAysxaxXMNkFD+qjpCAu7bYO2GYSgfWAWb0eqnxgqbtXUSmqU9u1nX+zrko9gcSvxIenRWJ9MDEFfXazkdGFV8j9q8AHOmeBSIiNt4n6P7fzYjyxB5CmiJ1rcA5rBLRnfRNQ== Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:24::27) by YTOPR0101MB2316.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b00:20::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.16; Sat, 5 Sep 2020 04:14:19 +0000 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20]) by YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20%6]) with mapi id 15.20.3348.017; Sat, 5 Sep 2020 04:14:19 +0000 From: Rick Macklem To: Alan Somers , FreeBSD Hackers Subject: Re: panic!("docallb") in nfsrv_docallback Thread-Topic: panic!("docallb") in nfsrv_docallback Thread-Index: AQHWgxtspJUVGlzLXkCTJBO3gNcFCalZaLF0 Date: Sat, 5 Sep 2020 04:14:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 80bfd280-0398-4548-262d-08d85152291b x-ms-traffictypediagnostic: YTOPR0101MB2316: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UZhKvJaOzF2q0Jc0Z1qCPnbW81d2cC0eImGhv5EsvFk3i2CzzsjedbyHYko4XHHC2YZKw3bNeO8y9cjMc4aJyZFLKiak2TzYWkULSQY2LU3SpJq2/4oDUyF55cyCTx2w9I7Wo+UGOsw7t4D1G/OYF7l9LRgW+XiC+Wa4K7/AxNGTi7Rzm6djLcZrrBcsq3++VwdpDz6uMRMYbXY8JpaeP2fyz65ZKE2Vl4GA5s52LugWM0ptPq46oaha+DbSzMG7fiCKncrXol/Nd96IB6oHlVjs2PFjxF0tKRuGQ7wjLBs/4k51ZDCYJe6DF0WwkcGmbwBhIXq1vnlgO19Sw0OCBQqG+pHEyljzf1PhHfnvsi9oyiOppdllJ4gOkybtdzVMXAoPQocdCqBXmH0jmQDNHA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(136003)(376002)(366004)(39860400002)(346002)(396003)(66446008)(7696005)(966005)(6506007)(9686003)(55016002)(66476007)(66556008)(64756008)(2906002)(450100002)(786003)(316002)(110136005)(8936002)(186003)(76116006)(478600001)(8676002)(66946007)(52536014)(71200400001)(91956017)(5660300002)(86362001)(83380400001)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ssrEHJhdODm9lmp6rB8jxQ1sXZxnYoX+KiHh6Ijrr/FI8SMhr/1vOrhnVcBMY2biNK3b/hoXOzRQhWAi4LPzdIcVWFNbOd5eWz48MvrzEPHcdoq+QHeMlf3IxE6SNZAT9vALax73IiWhjSQiaV/Va+feGYFzYm1vI9IMMh7RNFwi0e0DtSYNt1m0LCIzG4uoGLX5gx/CTeEI8taNA3+HuMgVkMAB34t/cbHQCUhK7QJsbStyJGgzgduF3trIbxXmU12wuhOez6XYXfHmsULtaR2okHm04pEeXC+DxC3/yES5BftwHdazb/M7sIdUX6Lrn/tmVtORdMVORzpDez1aWq9ASU3m+3ilNqVs/RW5WOdCVEHc3dvXBh3pKb2+maKqpnFU1HywQE8LMJV2DMQR+7FRPFpGNtC1SMHJ8eo03nNCQl3p/0GAN4wUfIIb8ywkAjPAxYGG1ITyKykC4sEpzyTPlKQ/26/rlU0jZzNt5/zChTbgJ/iF9iEWQjyXHPIiofkeEvoMz/uZvC3aP7BjGpyBsClQWY2yKWUGJO+ex4L7xE7FfrNDkJTNGm2Mf8jn6Aqy0EpiuhiZEmZBET+H9t4EgWQxvRMc/pk3lgbLAZ0ZeHqDbN1sBMoSVkvxS1O/ETiFbrrcHfDPa3yPZ92OSHtbK4Wu0SaULCPVGjYyPhM6/gkQyrLoPHK3+Cfuz7pMi0JO1fiADnsIR4mb6E6ppw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 80bfd280-0398-4548-262d-08d85152291b X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Sep 2020 04:14:19.0888 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: bvPV9/TKmOBZzAHeiLZN/EKQ0FuZIMH0KLA8WVvddyfoGHxoZ51Ncyp4CGRwBHAfsM2RwQwEHqVKsp9+93EyBw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB2316 X-Rspamd-Queue-Id: 4Bk1QP0pMRz3bLD X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=nC07dK4a; dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.71 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-6.21 / 15.00]; NEURAL_HAM_MEDIUM(-1.04)[-1.039]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.02)[-1.020]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; SUBJECT_HAS_EXCLAIM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[40.107.66.71:from]; DKIM_TRACE(0.00)[uoguelph.ca:+]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; NEURAL_HAM_SHORT(-1.15)[-1.154]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MAILMAN_DEST(0.00)[freebsd-hackers]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.66.71:from] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2020 04:14:22 -0000 Alan Somers wrote:=0A= >I just saw this panic on a 12-stable machine. Unfortunately, I don't have= =0A= >a core dump, just a stack trace. It was serving NFS v4.0, with delegation= s=0A= >enabled. The clients were all Debian, with Linux 3.16.0.=0A= >=0A= >The proximal cause of the panic seems to be that the file had a write=0A= >delegation issued to an unconfirmed client. Root cause is harder to=0A= >determine. Did the kernel previously issue a delegation to an unconfirmed= =0A= >client? Or did the client somehow change to an unconfirmed state after th= e=0A= >delegation was issued, perhaps due to a race?=0A= >=0A= >It's hard to tell, but I don't see any checks for lc_flags &=0A= >LCL_NEEDSCONFIRM in nfsrv_openctrl (which issues the delegations), so I'm= =0A= >guessing that that's the problem.=0A= I guess I should have looked at the code before doing the last post.=0A= The check is in nfsrv_getclient(), that is called by nfsrv_opencheck().=0A= nfsrv_opencheck() - Checks to see if an Open is allowed.=0A= nfsrv_openctrl() - Does the Open, assuming nfsrv_opencheck() determined it= =0A= was allowed.=0A= =0A= > If so, then the event trace would look=0A= >like this:=0A= >=0A= >1) Client Alice sends SETCLIENTID. The server creates a client state=0A= >structure=0A= > for her.=0A= >_) Client Alice should've sent SETCLIENTID_CONFIRM, but doesn't. Bad Alic= e!=0A= >2) Client Alice sends OPEN for some file, and is issued a write delegation= .=0A= > The server shouldn't have issued it, because Alice's client ID is=0A= > unconfirmed. Bad server!=0A= I don't think this can happen. From looking at the code, an NFSERR_EXPIRED= =0A= reply to the Open should have happened.=0A= =0A= >3) Client Bob tries to do a GETATTR on that same file.=0A= >4) In nfsrv_checkgetattr, the kernel finds a write delegation for that fil= e,=0A= > owned by client Alice.=0A= I think the server needs to check for LCL_NEEDSCONFIRM in here.=0A= It gets the "clp" from the FH, but it "assumes" a confirmed ClientID.=0A= =0A= I'll code up a patch to add this check to nfsrv_checkgetattr().=0A= =0A= >5) The kernel tries to send a NFSV4OP_CBGETATTR callback to Alice, to see= =0A= >if the=0A= > file's attributes have changed.=0A= >6) But Alice's client ID is unconfirmed. Oh no! Panic!=0A= >=0A= >Does this sound plausible? Should there be a check for LCL_NEEDSCONFIRM= =0A= >somewhere around line 3166 in nfs_nfsdstate.c? Grateful for any help.=0A= Well, it doesn't appear that the Open could occur when the ClientID was=0A= not confirmed.=0A= --> The obvious case you listed above is caught by nfsrv_opencheck().=0A= Now, could a SetClientID happen between nfsrv_opencheck() and=0A= nfsrv_openctrl()?=0A= --> I don't think so. If you look at nfsrv_setclient() which does Set= ClientID,=0A= it grabs the nfsv4rootfs_lock, locking out all other nfsd thre= ads.=0A= It can't acquire the lock while a "shared lock" (I called a re= fcnt) is=0A= held by any other nfsd thread and the thread doing an Open wil= l=0A= hold the shared lock (refcnt).=0A= =0A= So, I think the Open with delegation would have been issued when the=0A= ClientID was confirmed.=0A= --> Then I suspect the client did another SetClientID that put the ClientID= =0A= back to unconfirmed (the obvious one is a client reboot).=0A= --> One quirk of SetClientID/SetClientIDConfirm is that old Open/Loc= k=0A= state cannot be discarded until it is confirmed, so the old De= legations=0A= would remain on the ClientID.=0A= --> Then a client did a Getattr on the file that had the old Delegation sti= ll=0A= allocated to it.=0A= =0A= I'd definitely say that nfsrv_checkgetattr() needs to check for an unconfir= med=0A= ClientID and return without attempting a callback.=0A= --> The exclusive lock on nfsv4rootfs_lock acquired when doing SetClientID= =0A= should also guarantee that, if the ClientID is confirmed when=0A= nfsrv_checkgetattr() tests for it, it will remain that way until aft= er the=0A= callback is completed.=0A= =0A= I'll come up with a patch and stick it on phabricator, rick=0A= =0A= =0A= =0A= -Alan=0A= =0A= P.S.: stack trace=0A= =0A= kdb_backtrace=0A= vpanic=0A= panic=0A= nfsrv_docallback=0A= nfsrv_checkgetattr=0A= nfsrvd_getattr=0A= nfsrvd_dorpc=0A= nfssvc_program=0A= svc_run_internal=0A= svc_thread_start=0A= fork_exit=0A= fork_trampoline=0A= _______________________________________________=0A= freebsd-hackers@freebsd.org mailing list=0A= https://lists.freebsd.org/mailman/listinfo/freebsd-hackers=0A= To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= =0A= =0A=