From: Jakub Kicinski <kuba@kernel.org>
To: Nikolay Aleksandrov <razor@blackwall.org>
Cc: nicolas.dichtel@6wind.com,
Florent Fourcot <florent.fourcot@wifirst.fr>,
netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com, Johannes Berg <johannes@sipsolutions.net>,
Pablo Neira Ayuso <pablo@netfilter.org>,
Florian Westphal <fw@strlen.de>,
Jamal Hadi Salim <jhs@mojatatu.com>,
Jacob Keller <jacob.e.keller@intel.com>,
Guillaume Nault <gnault@redhat.com>,
Hangbin Liu <liuhangbin@gmail.com>
Subject: Re: [PATCH net-next] docs: netlink: clarify the historical baggage of Netlink flags
Date: Wed, 28 Sep 2022 07:37:09 -0700 [thread overview]
Message-ID: <20220928073709.1b93b74a@kernel.org> (raw)
In-Reply-To: <e4db8d52-5bbb-8667-86a6-c7a2154598d1@blackwall.org>
On Wed, 28 Sep 2022 12:21:57 +0300 Nikolay Aleksandrov wrote:
> On 28/09/2022 11:55, Nicolas Dichtel wrote:
> > Le 28/09/2022 à 10:04, Florent Fourcot a écrit :
> >> About NLM_F_EXCL, I'm not sure that my comment is relevant for your intro.rst
> >> document, but it has another usage in ipset submodule. For IPSET_CMD_DEL,
> >> setting NLM_F_EXCL means "raise an error if entry does not exist before the
> >> delete".
Interesting.
> > So NLM_F_EXCL could be used with DEL command for netfilter netlink but cannot be
> > used (it overlaps with NLM_F_BULK, see [1]) with DEL command for rtnetlink.
> > Sigh :(
> >
> > [1] https://lore.kernel.org/netdev/0198618f-7b52-3023-5e9f-b38c49af1677@6wind.com/
>
> One could argue that's abuse of the api, but since it's part of a different family
> I guess it's ok. NLM_F_EXCL is a modifier of NEW cmd as the comment above it says
> and has never had rtnetlink DEL users.
It's fine in the sense that it works, but it's rather pointless to call
the flags common if they have different semantics depending on the
corner of the kernel they are used in, right?
I was very tempted to send a patch which would validate the top
byte of flags in genetlink for new commands, this way we may some day
find a truly common (as in enforced by the code) use for the bits.
WDYT?
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index 7c136de117eb..0fbaed49e23f 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -739,6 +739,22 @@ static int genl_family_rcv_msg_doit(const struct genl_family *family,
return err;
}
+static int genl_header_check(struct nlmsghdr *nlh, struct genlmsghdr *hdr)
+{
+ if (hdr->reserved)
+ return -EINVAL;
+
+ /* Flags - lower byte check */
+ if (nlh->nlmsg_flags & 0xff & ~(NLM_F_REQUEST | NLM_F_ACK | NLM_F_ECHO))
+ return -EINVAL;
+ /* Flags - higher byte check */
+ if (nlh->nlmsg_flags & 0xff00 &&
+ nlh->nlmsg_flags & 0xff00 != NLM_F_DUMP)
+ return -EINVAL;
+
+ return 0;
+}
+
static int genl_family_rcv_msg(const struct genl_family *family,
struct sk_buff *skb,
struct nlmsghdr *nlh,
@@ -757,7 +773,7 @@ static int genl_family_rcv_msg(const struct genl_family *family,
if (nlh->nlmsg_len < nlmsg_msg_size(hdrlen))
return -EINVAL;
- if (hdr->cmd >= family->resv_start_op && hdr->reserved)
+ if (hdr->cmd >= family->resv_start_op && genl_header_check(nlh, hdr))
return -EINVAL;
if (genl_get_cmd(hdr->cmd, family, &op))
next prev parent reply other threads:[~2022-09-28 14:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-27 21:23 [PATCH net-next] docs: netlink: clarify the historical baggage of Netlink flags Jakub Kicinski
2022-09-28 7:03 ` Nikolay Aleksandrov
2022-09-28 14:21 ` Jakub Kicinski
2022-09-28 14:40 ` Nikolay Aleksandrov
2022-09-28 14:43 ` Nikolay Aleksandrov
2022-09-30 11:07 ` Jamal Hadi Salim
2022-09-30 11:29 ` Nikolay Aleksandrov
2022-09-30 14:24 ` Jamal Hadi Salim
2022-09-30 14:34 ` Nikolay Aleksandrov
2022-09-30 16:36 ` Jamal Hadi Salim
2022-09-30 18:19 ` Nikolay Aleksandrov
2022-10-02 13:59 ` Jamal Hadi Salim
2022-09-28 8:04 ` Florent Fourcot
2022-09-28 8:55 ` Nicolas Dichtel
2022-09-28 9:21 ` Nikolay Aleksandrov
2022-09-28 14:37 ` Jakub Kicinski [this message]
2022-09-28 14:46 ` Nikolay Aleksandrov
2022-09-28 15:15 ` Jakub Kicinski
2022-09-28 15:19 ` Nicolas Dichtel
2022-09-30 2:21 ` patchwork-bot+netdevbpf
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=20220928073709.1b93b74a@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=florent.fourcot@wifirst.fr \
--cc=fw@strlen.de \
--cc=gnault@redhat.com \
--cc=jacob.e.keller@intel.com \
--cc=jhs@mojatatu.com \
--cc=johannes@sipsolutions.net \
--cc=liuhangbin@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=nicolas.dichtel@6wind.com \
--cc=pabeni@redhat.com \
--cc=pablo@netfilter.org \
--cc=razor@blackwall.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).