From: Gur Stavi <gur.stavi@huawei.com>
To: 'Willem de Bruijn' <willemdebruijn.kernel@gmail.com>
Cc: <davem@davemloft.net>, <edumazet@google.com>, <kuba@kernel.org>,
<linux-kernel@vger.kernel.org>, <linux-kselftest@vger.kernel.org>,
<netdev@vger.kernel.org>, <pabeni@redhat.com>, <shuah@kernel.org>
Subject: RE: [PATCH net-next v02 1/2] af_packet: allow fanout_add when socket is not RUNNING
Date: Fri, 11 Oct 2024 12:02:05 +0300 [thread overview]
Message-ID: <000301db1bbc$453feae0$cfbfc0a0$@huawei.com> (raw)
In-Reply-To: <67085135e4fe2_21530629429@willemb.c.googlers.com.notmuch>
>
> If we don't care about opening up fanout groups to ETH_P_NONE, then
> patch v2 seems sufficient. If explicitly blocking this, the ENXIO
> return can be added, but ideally without touching the other lines.
I don't think that allowing ETH_P_NONE is relevant.
In my opinion the 2 options that should be considered to fail
fanout_add are:
1. Testing proto == 0
2. Testing proto == 0 || ifindex == -1
The only corner case that is caught by [2] and missed by [1] is
the "unlisted" case during do_bind. It is such a rare case that
probably no one will ever encounter bind "unlisted" followed by
FANOUT_ADD. And this is not a dangerous corner case that leads to
system crash.
However, being a purist, I see the major goal of code review to promote
correctness by identifying corner cases while improving style is a
secondary priority. Since we did identify this corner case in our
discussion I think we should still use [2].
I don't consider the code complex. In fact, to me, the ifindex clause
is a more understandable direct reason for failure than the proto which
is indirect. Having the ifindex clause helps figuring out the proto
clause.
next prev parent reply other threads:[~2024-10-11 9:02 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-08 10:27 [PATCH net-next v02 0/2] net: af_packet: allow joining a fanout when link is down Gur Stavi
2024-10-08 10:27 ` [PATCH net-next v02 1/2] af_packet: allow fanout_add when socket is not RUNNING Gur Stavi
2024-10-08 14:26 ` Willem de Bruijn
2024-10-09 6:58 ` Gur Stavi
2024-10-09 13:51 ` Willem de Bruijn
2024-10-09 18:03 ` Gur Stavi
2024-10-10 0:30 ` Willem de Bruijn
2024-10-10 7:08 ` Gur Stavi
2024-10-10 14:21 ` Willem de Bruijn
2024-10-10 16:14 ` Gur Stavi
2024-10-10 22:12 ` Willem de Bruijn
2024-10-11 5:17 ` Gur Stavi
2024-10-11 14:24 ` Willem de Bruijn
2024-10-11 9:02 ` Gur Stavi [this message]
2024-10-11 14:35 ` Willem de Bruijn
2024-10-11 17:12 ` Gur Stavi
2024-10-11 19:08 ` Willem de Bruijn
2024-10-10 11:49 ` Gur Stavi
2024-10-08 10:27 ` [PATCH net-next v02 2/2] selftests: net/psock_fanout: socket joins fanout when link is down Gur Stavi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='000301db1bbc$453feae0$cfbfc0a0$@huawei.com' \
--to=gur.stavi@huawei.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shuah@kernel.org \
--cc=willemdebruijn.kernel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.