[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZHByhjt2xYf5xKAu@gmail.com>
Date: Fri, 26 May 2023 01:49:10 -0700
From: Breno Leitao <leitao@...ian.org>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: dsahern@...nel.org, Remi Denis-Courmont <courmisch@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Alexander Aring <alex.aring@...il.com>,
Stefan Schmidt <stefan@...enfreihafen.org>,
Miquel Raynal <miquel.raynal@...tlin.com>,
Matthieu Baerts <matthieu.baerts@...sares.net>,
Mat Martineau <martineau@...nel.org>,
Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
Xin Long <lucien.xin@...il.com>, leit@...com, axboe@...nel.dk,
asml.silence@...il.com, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, dccp@...r.kernel.org,
linux-wpan@...r.kernel.org, mptcp@...ts.linux.dev,
linux-sctp@...r.kernel.org
Subject: Re: [PATCH net-next v3] net: ioctl: Use kernel memory on protocol
ioctl callbacks
On Thu, May 25, 2023 at 11:05:40AM -0400, Willem de Bruijn wrote:
> On Thu, May 25, 2023 at 8:55 AM Breno Leitao <leitao@...ian.org> wrote:
> > @@ -1547,6 +1547,28 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, sockptr_t optval,
> > return ret;
> > }
> >
> > +/* Execute if this ioctl is a special mroute ioctl */
> > +int ipmr_sk_ioctl(struct sock *sk, unsigned int cmd, void __user *arg)
> > +{
> > + switch (cmd) {
> > + /* These userspace buffers will be consumed by ipmr_ioctl() */
> > + case SIOCGETVIFCNT: {
> > + struct sioc_vif_req buffer;
> > +
> > + return sock_ioctl_inout(sk, cmd, arg, &buffer,
> > + sizeof(buffer));
> > + }
>
> More importantly, if we go down the path of demultiplexing in protocol
> independent code to call protocol specific handlers, then there there
> is no need to have them call protocol independent helpers like
> sock_ioct_inout again. Just call the protocol-specific ioctl handlers
> directly?
That is what I was expecting, but, the code is exactly the same and I
kept it in the generic section. This is what this code needs to do:
* Copy X byte from userspace
* sk->sk_prot->ioctl()
* Copy X bytes back to userspace
I tried to keep the code generic enough that it could be reused.
I can definitely push the same code to two different protocols, if you
prefer, no strong opinion.
Powered by blists - more mailing lists