From nobody Fri Apr 07 06:34:30 2023 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Pt7rf5mpcz44DSW for ; Fri, 7 Apr 2023 06:34:42 +0000 (UTC) (envelope-from zlei@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Pt7rf3xt3z44Km; Fri, 7 Apr 2023 06:34:42 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1680849282; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MDVJxpwFVZeD37MKvsN6T+GyJgcra0KfZQc8X9/J+Ik=; b=h+TDL2uhbvvs4v/nKi1n+08dkaq11VBtDXtA9ApwIH1WNenpItOukQuOHC6mkGfFzCOnG/ VW7SmOp7+sfPAFqPIKoCN2eRRRzvd0jGcHbOlNHrrln1V3rtBlMzfa7idXWU5YU4V/TVFH YCA5nUj5SjTTMgsOu2Fj8EHZ2ITFRpe2OdUXgC7gmRV2B0JtNzjUa5N21lWCi0SJtJV7OW uOQXle46OAPjZrf/PhVoZDSSqsvsthfQnLj/TkRi1PKj+85pEqnh68reov6IZAiKSJW2OD 6iL8FIZzUYpZc0nTZTYYBJFEgrey/d1XJ3tx+92HXNlclfJwPL7UTPA4AMkG0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1680849282; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MDVJxpwFVZeD37MKvsN6T+GyJgcra0KfZQc8X9/J+Ik=; b=Bdl+XTtNaK2NQ9M/wlrBMun+ALp0mGmKmIvyo+jB7tTl+N9FS/5a5+8JdzEev7UZNkfEst SWWJFzKr+86WVNVhjJxRDbLpSi+sJLkIGrg8JZPuXUJeCoNmll5KGhHFy5zsCd9eH0vPyR VBRyjmpZsmAP+ttwCUw/H+SsPN1ztmF9Cgdd3lPP5lSBEnBV3dtpo/44nAeyc1mTk8GPtK eOhIiVzIpnpBwLnL12JEMRCtf7K6jp/v9rc7DergVF3CfeX9rzxMXfK3sJuCQcHNX975jn 5+h27vmTZluZIrC2PvR2JZPlMyBBRU6+0DZEFElOiEQIMNm+w8XUw1eQDYgIhQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1680849282; a=rsa-sha256; cv=none; b=G6A97BBleohsmFcDNaY81pOpnZvz6ikr5VLgvlO3lczZqKIuTxYwk+qk7iXWHDcj7lSDMj KAVYkoDkgiyWbA2jJmtDDGi4bR22NY4yVag9mhIPdgCmB/iGzjwb0rTwwI1c57C64klVTd w+GUV2HNcCGsgWInlCJm/t/QrQYddUQhiqqV7ql6wE8c4k/ye2szCNEiiSITGVyw3y5lH6 ZKmtuQKPMgreHvdvqmvtlEevALTkPVWOe5ZqliSuZeyTqcW7gC4+ghIyfSqG7hDI2zn6a4 +be+1fyZwBj9Yfogynhp/kmSnwtoYzVWRzxYfa2hyVUQs1P3LH5D/eL+UfVLMw== Received: from smtpclient.apple (unknown [IPv6:2001:19f0:6001:9db:98f0:9fe0:3545:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Pt7rc0tZMzyQj; Fri, 7 Apr 2023 06:34:39 +0000 (UTC) (envelope-from zlei@FreeBSD.org) From: Zhenlei Huang Message-Id: <2F8A1A63-642C-44C2-9319-A750B381EC70@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_4B2E8384-2205-4739-9F01-C10F9B8F1818" List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.2\)) Subject: Re: IFF_KNOWSEPOCH -> IFF_NEEDSEPOCH Date: Fri, 7 Apr 2023 14:34:30 +0800 In-Reply-To: Cc: hselasky@freebsd.org, kib@freebsd.org, bz@freebsd.org, gallatin@freebsd.org, current@freebsd.org To: Gleb Smirnoff References: X-Mailer: Apple Mail (2.3696.120.41.1.2) X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_4B2E8384-2205-4739-9F01-C10F9B8F1818 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On Apr 7, 2023, at 2:34 AM, Gleb Smirnoff wrote: > > Hi, > > recently we had several drivers marked with IFF_KNOWSEPOCH > which reminded me that this flag was supposed to be temporary. > > Here is the change that introduced it e87c4940156. It was > caused by several drivers sending packets from non-interrupt > context and thus triggering NET_EPOCH_ASSERT(). It was about > 10 - 20 drivers having this problem initially and reduced down > to a few after 4426b2e64bd. We had a pretty heated dicussion > back then and I apologize for that. > > May I suggest before entering FreeBSD 14.0-RELEASE cycle we > will get back to what was there before e87c4940156? It sounds good if only a few drivers need IFF_NEEDSEPOCH. > > To avoid the driver fallout that we used to have back in > early 2020, here is the plan. In ether_input() where we > now conditionally on the IFF_KNOWSEPOCH flag enter/exit the > epoch with INVARIANTS we will also conditionally enter/exit > in case we are supposed to be in the epoch wrt the flag, but > we are not. We will also print a warning once, like "interface > foo0 called if_input without epoch". This handling will be > converted to normal assertion after a couple months. Should also apply to infiniband_input(). BTW, is `in_epoch()` too heavy to replace flag IFF_NEEDSEPOCH or IFF_KNOWSEPOCH ? > > If everybody is fine with this suggestion I will post > a review. Otherwise please express your concerns. Good to make it moving forward ;) Best regards, Zhenlei > > -- > Gleb Smirnoff --Apple-Mail=_4B2E8384-2205-4739-9F01-C10F9B8F1818 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Apr 7, 2023, at 2:34 AM, Gleb Smirnoff <glebius@freebsd.org>= wrote:

 Hi,

recently we had = several drivers marked with IFF_KNOWSEPOCH
which reminded = me that this flag was supposed to be temporary.

Here is the change that introduced it e87c4940156. It was
caused by several drivers sending packets from = non-interrupt
context and thus triggering = NET_EPOCH_ASSERT(). It was about
10 - 20 drivers having = this problem initially and reduced down
to a few after = 4426b2e64bd. We had a pretty heated dicussion
back then = and I apologize for that.

May I suggest = before entering FreeBSD 14.0-RELEASE cycle we
will get = back to what was there before e87c4940156?

It = sounds good if only a few drivers need IFF_NEEDSEPOCH.


To avoid the driver fallout that we used to = have back in
early 2020, here is the plan. In = ether_input() where we
now conditionally on the = IFF_KNOWSEPOCH flag enter/exit the
epoch with INVARIANTS = we will also conditionally enter/exit
in case we are = supposed to be in the epoch wrt the flag, but
we are not. = We will also print a warning once, like "interface
foo0 = called if_input without epoch". This handling will be
converted to normal assertion after a couple months.

Should = also apply to infiniband_input().

BTW, is `in_epoch()` too heavy to replace = flag IFF_NEEDSEPOCH
or IFF_KNOWSEPOCH = ?


If everybody = is fine with this suggestion I will post
a review. = Otherwise please express your concerns.

Good = to make it moving forward ;)

Best = regards,
Zhenlei


--
Gleb Smirnoff


= --Apple-Mail=_4B2E8384-2205-4739-9F01-C10F9B8F1818--