All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: David Miller <davem@davemloft.net>
Cc: hch@lst.de, kuba@kernel.org, kuznet@ms2.inr.ac.ru,
	yoshfuji@linux-ipv6.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/4] ipv6: symbol_get to access a sit symbol
Date: Fri, 15 May 2020 08:33:24 +0200	[thread overview]
Message-ID: <20200515063324.GA31377@lst.de> (raw)
In-Reply-To: <20200514.175355.167885308958584692.davem@davemloft.net>

On Thu, May 14, 2020 at 05:53:55PM -0700, David Miller wrote:
> You're not undoing one, but two levels of abstraction here.
> 
> Is this "ipip6_tunnel_locate()" call part of the SIT ioctl implementation?

Yes.  Take a look at the convoluted case handling the
SIOCADDTUNNEL and SIOCCHGTUNNEL commands in ipip6_tunnel_ioctl.

> Where did it come from?   Why are ->ndo_do_ioctl() implementations no longer
> allowed from here?

The problem is that we feed kernel pointers to it, which requires
set_fs address space overrides that I plan to kill off entirely.

> Honestly, this feels like a bit much.

My initial plan was to add a ->tunnel_ctl method to the net_device_ops,
and lift the copy_{to,from}_user for SIOCADDTUNNEL, SIOCCHGTUNNEL,
SIOCDELTUNNEL and maybe SIOCGETTUNNEL to net/socket.c.  But that turned
out to have two problems:

 - first these ioctls names use SIOCDEVPRIVATE range, that can also
   be implemented by other drivers
 - the ip_tunnel_parm struture is only used by the ipv4 tunneling
   drivers (including sit), the "real" ipv6 tunnels use a
   ip6_tnl_parm or ip6_tnl_parm structure instead

But if you don't like the symbol_get approach, I could do the
tunnel_ctl operation, just for the іpv4-ish tunnels, and only for
the kernel callers.

---end quoted text---

  reply	other threads:[~2020-05-15  6:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-14 14:50 use symbol_get to create the magic ipv4/ipv6 tunnels Christoph Hellwig
2020-05-14 14:50 ` [PATCH 1/4] ipv4: streamline ipmr_new_tunnel Christoph Hellwig
2020-05-14 14:50 ` [PATCH 2/4] ipv4: consolidate the VIFF_TUNNEL handling in ipmr_new_tunnel Christoph Hellwig
2020-05-14 14:51 ` [PATCH 3/4] ipv4: use symbol_get to access ipip symbols Christoph Hellwig
2020-05-14 14:51 ` [PATCH 4/4] ipv6: symbol_get to access a sit symbol Christoph Hellwig
2020-05-15  0:53   ` David Miller
2020-05-15  6:33     ` Christoph Hellwig [this message]
2020-05-16 20:55       ` David Miller
2020-05-18  6:30         ` Christoph Hellwig
2020-05-19  0:36           ` David Miller

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=20200515063324.GA31377@lst.de \
    --to=hch@lst.de \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=yoshfuji@linux-ipv6.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.