From: Breno Leitao <leitao@debian.org>
To: dccp@vger.kernel.org
Subject: Re: [PATCH net-next v3] net: ioctl: Use kernel memory on protocol ioctl callbacks
Date: Fri, 26 May 2023 09:08:20 +0000 [thread overview]
Message-ID: <ZHB3BNopbx+5AnIa@gmail.com> (raw)
In-Reply-To: <20230525125503.400797-1-leitao@debian.org>
On Thu, May 25, 2023 at 12:06:00PM -0400, Willem de Bruijn wrote:
> On Thu, May 25, 2023 at 11:34 AM David Ahern <dsahern@kernel.org> wrote:
> > On 5/25/23 9:05 AM, Willem de Bruijn wrote:
> > > I don't understand what this buys us vs testing the sk_family,
> > > sk_protocol and cmd here.
> >
> > To keep protocol specific code out of core files is the reason I
> > suggested it.
>
> I guess you object to demultiplexing based on per-family
> protocol and ioctl cmd constants directly in this file?
>
> That only requires including the smaller uapi headers.
>
> But now net/core/sock.h now still has to add includes
> linux/mroute.h, linux/mroute6.h and net/phonet/phonet.h.
>
> Aside on phonet_is_sk, if we're keeping this: this should be
> sk_is_phonet? Analogous to sk_is_tcp and such. And, it should suffice
> to demultiplex based on the protocol family, without testing the
> type or protocol. The family is defined in protocol-independent header
> linux/socket.h. The differences between
> PN_PROTO_PHONET and PN_PROTO_PIPE should be handled inside the family
> code. So I think it is cleaner just to open-coded as `if
> (sk->sk_family = PF_PHONET)`
Should we do the same for ipmr as well? Currently I am checking it
using:
return sk->sk_type = SOCK_RAW && inet_sk(sk)->inet_num = IPPROTO_ICMPV6;
This is what ip{6}mr functions[1] are use to check if `sk` is using ip{6}mr.
If we just use `sk->family`, then I suppose that `sk_is_ip6mr` would be
something as coded below. Is this correct?
static inline int sk_is_ip6mr(struct sock *sk)
{
return sk->sk_family = PF_INET6;
}
Anyway, should we continue with the current (V3) approach, where we keep
the protocol code out of core files, or, should I come back to the
previous (V2) approach, where the protocol checks is coded directly in
the core file?
Thanks for the review!
[1] Link: https://github.com/torvalds/linux/blob/0d85b27b0cc6b5cf54567c5ad913a247a71583ce/net/ipv6/ip6mr.c#L1666
WARNING: multiple messages have this Message-ID (diff)
From: Breno Leitao <leitao@debian.org>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: David Ahern <dsahern@kernel.org>,
Remi Denis-Courmont <courmisch@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Alexander Aring <alex.aring@gmail.com>,
Stefan Schmidt <stefan@datenfreihafen.org>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Matthieu Baerts <matthieu.baerts@tessares.net>,
Mat Martineau <martineau@kernel.org>,
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
Xin Long <lucien.xin@gmail.com>,
leit@fb.com, axboe@kernel.dk, asml.silence@gmail.com,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
dccp@vger.kernel.org, linux-wpan@vger.kernel.org,
mptcp@lists.linux.dev, linux-sctp@vger.kernel.org
Subject: Re: [PATCH net-next v3] net: ioctl: Use kernel memory on protocol ioctl callbacks
Date: Fri, 26 May 2023 02:08:20 -0700 [thread overview]
Message-ID: <ZHB3BNopbx+5AnIa@gmail.com> (raw)
In-Reply-To: <CAF=yD-LXcufhJBpkEcUuphFpR1TA4=QwUXw4sKFsSiEL_mwG4Q@mail.gmail.com>
On Thu, May 25, 2023 at 12:06:00PM -0400, Willem de Bruijn wrote:
> On Thu, May 25, 2023 at 11:34 AM David Ahern <dsahern@kernel.org> wrote:
> > On 5/25/23 9:05 AM, Willem de Bruijn wrote:
> > > I don't understand what this buys us vs testing the sk_family,
> > > sk_protocol and cmd here.
> >
> > To keep protocol specific code out of core files is the reason I
> > suggested it.
>
> I guess you object to demultiplexing based on per-family
> protocol and ioctl cmd constants directly in this file?
>
> That only requires including the smaller uapi headers.
>
> But now net/core/sock.h now still has to add includes
> linux/mroute.h, linux/mroute6.h and net/phonet/phonet.h.
>
> Aside on phonet_is_sk, if we're keeping this: this should be
> sk_is_phonet? Analogous to sk_is_tcp and such. And, it should suffice
> to demultiplex based on the protocol family, without testing the
> type or protocol. The family is defined in protocol-independent header
> linux/socket.h. The differences between
> PN_PROTO_PHONET and PN_PROTO_PIPE should be handled inside the family
> code. So I think it is cleaner just to open-coded as `if
> (sk->sk_family == PF_PHONET)`
Should we do the same for ipmr as well? Currently I am checking it
using:
return sk->sk_type == SOCK_RAW && inet_sk(sk)->inet_num == IPPROTO_ICMPV6;
This is what ip{6}mr functions[1] are use to check if `sk` is using ip{6}mr.
If we just use `sk->family`, then I suppose that `sk_is_ip6mr` would be
something as coded below. Is this correct?
static inline int sk_is_ip6mr(struct sock *sk)
{
return sk->sk_family == PF_INET6;
}
Anyway, should we continue with the current (V3) approach, where we keep
the protocol code out of core files, or, should I come back to the
previous (V2) approach, where the protocol checks is coded directly in
the core file?
Thanks for the review!
[1] Link: https://github.com/torvalds/linux/blob/0d85b27b0cc6b5cf54567c5ad913a247a71583ce/net/ipv6/ip6mr.c#L1666
next prev parent reply other threads:[~2023-05-26 9:08 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-25 12:54 [PATCH net-next v3] net: ioctl: Use kernel memory on protocol ioctl callbacks Breno Leitao
2023-05-25 12:54 ` Breno Leitao
2023-05-25 14:19 ` Eric Dumazet
2023-05-25 14:19 ` Eric Dumazet
2023-05-25 14:54 ` Simon Horman
2023-05-25 14:54 ` Simon Horman
2023-05-25 15:03 ` David Ahern
2023-05-25 15:03 ` David Ahern
2023-05-25 15:05 ` Willem de Bruijn
2023-05-25 15:05 ` Willem de Bruijn
2023-05-25 15:16 ` net: ioctl: Use kernel memory on protocol ioctl callbacks: Tests Results MPTCP CI
2023-05-25 15:34 ` [PATCH net-next v3] net: ioctl: Use kernel memory on protocol ioctl callbacks David Ahern
2023-05-25 15:34 ` David Ahern
2023-05-25 16:06 ` Willem de Bruijn
2023-05-25 16:06 ` Willem de Bruijn
2023-05-26 1:15 ` kernel test robot
2023-05-26 8:49 ` Breno Leitao
2023-05-26 8:49 ` Breno Leitao
2023-05-26 9:08 ` Breno Leitao [this message]
2023-05-26 9:08 ` Breno Leitao
2023-05-26 14:09 ` Willem de Bruijn
2023-05-26 14:09 ` Willem de Bruijn
2023-05-28 18:05 ` kernel test robot
2023-05-28 18:05 ` kernel test robot
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=ZHB3BNopbx+5AnIa@gmail.com \
--to=leitao@debian.org \
--cc=dccp@vger.kernel.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 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.