From: Guillaume Nault <gnault@redhat.com>
To: Tom Parkin <tparkin@katalix.com>
Cc: netdev@vger.kernel.org, jchapman@katalix.com
Subject: Re: [RFC PATCH 1/2] ppp: add PPPIOCBRIDGECHAN ioctl
Date: Tue, 10 Nov 2020 00:24:01 +0100 [thread overview]
Message-ID: <20201109232401.GM2366@linux.home> (raw)
In-Reply-To: <20201106181647.16358-2-tparkin@katalix.com>
On Fri, Nov 06, 2020 at 06:16:46PM +0000, Tom Parkin wrote:
> This new ioctl allows two ppp channels to be bridged together: frames
> arriving in one channel are transmitted in the other channel and vice
> versa.
>
> The practical use for this is primarily to support the L2TP Access
> Concentrator use-case. The end-user session is presented as a ppp
> channel (typically PPPoE, although it could be e.g. PPPoA, or even PPP
> over a serial link) and is switched into a PPPoL2TP session for
> transmission to the LNS. At the LNS the PPP session is terminated in
> the ISP's network.
>
> When a PPP channel is bridged to another it takes a reference on the
> other's struct ppp_file. This reference is dropped when the channel is
> unregistered: if the dereference causes the bridged channel's reference
> count to reach zero it is destroyed at that point.
> ---
> drivers/net/ppp/ppp_generic.c | 35 +++++++++++++++++++++++++++++++++-
> include/uapi/linux/ppp-ioctl.h | 1 +
> 2 files changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
> index 7d005896a0f9..d893bf4470f4 100644
> --- a/drivers/net/ppp/ppp_generic.c
> +++ b/drivers/net/ppp/ppp_generic.c
> @@ -175,6 +175,7 @@ struct channel {
> struct net *chan_net; /* the net channel belongs to */
> struct list_head clist; /* link in list of channels per unit */
> rwlock_t upl; /* protects `ppp' */
> + struct channel *bridge; /* "bridged" ppp channel */
> #ifdef CONFIG_PPP_MULTILINK
> u8 avail; /* flag used in multilink stuff */
> u8 had_frag; /* >= 1 fragments have been sent */
> @@ -641,8 +642,9 @@ static long ppp_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
> }
>
> if (pf->kind == CHANNEL) {
> - struct channel *pch;
> + struct channel *pch, *pchb;
> struct ppp_channel *chan;
> + struct ppp_net *pn;
>
> pch = PF_TO_CHANNEL(pf);
>
> @@ -657,6 +659,24 @@ static long ppp_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
> err = ppp_disconnect_channel(pch);
> break;
>
> + case PPPIOCBRIDGECHAN:
> + if (get_user(unit, p))
> + break;
> + err = -ENXIO;
> + if (pch->bridge) {
> + err = -EALREADY;
> + break;
> + }
> + pn = ppp_pernet(current->nsproxy->net_ns);
> + spin_lock_bh(&pn->all_channels_lock);
> + pchb = ppp_find_channel(pn, unit);
> + if (pchb) {
> + refcount_inc(&pchb->file.refcnt);
> + pch->bridge = pchb;
I think we shouldn't modify ->bridge if it's already set or if the
channel is already part of of a PPP unit (that is, if pch->ppp or
pch->bridge is not NULL).
This also means that we have to use appropriate locking.
> + err = 0;
> + }
> + spin_unlock_bh(&pn->all_channels_lock);
> + break;
> default:
> down_read(&pch->chan_sem);
> chan = pch->chan;
> @@ -2100,6 +2120,12 @@ ppp_input(struct ppp_channel *chan, struct sk_buff *skb)
> return;
> }
>
> + if (pch->bridge) {
> + skb_queue_tail(&pch->bridge->file.xq, skb);
The bridged channel might reside in a different network namespace.
So it seems that skb_scrub_packet() is needed before sending the
packet.
> + ppp_channel_push(pch->bridge);
I'm not sure if the skb_queue_tail()/ppp_channel_push() sequence really
is necessary. We're not going through a PPP unit, so we have no risk of
recursion here. Also, if ->start_xmit() fails, I see no reason for
requeuing the skb, like __ppp_channel_push() does. I'd have to think
more about it, but I believe that we could call the channel's
->start_xmit() function directly (respecting the locking constraints
of course).
> + return;
> + }
> +
> read_lock_bh(&pch->upl);
> if (!ppp_decompress_proto(skb)) {
> kfree_skb(skb);
> @@ -2791,6 +2817,13 @@ ppp_unregister_channel(struct ppp_channel *chan)
> up_write(&pch->chan_sem);
> ppp_disconnect_channel(pch);
>
> + /* Drop our reference on a bridged channel, if any */
> + if (pch->bridge) {
> + if (refcount_dec_and_test(&pch->bridge->file.refcnt))
> + ppp_destroy_channel(pch->bridge);
> + pch->bridge = NULL;
> + }
> +
> pn = ppp_pernet(pch->chan_net);
> spin_lock_bh(&pn->all_channels_lock);
> list_del(&pch->list);
> diff --git a/include/uapi/linux/ppp-ioctl.h b/include/uapi/linux/ppp-ioctl.h
> index 7bd2a5a75348..4b97ab519c19 100644
> --- a/include/uapi/linux/ppp-ioctl.h
> +++ b/include/uapi/linux/ppp-ioctl.h
> @@ -115,6 +115,7 @@ struct pppol2tp_ioc_stats {
> #define PPPIOCATTCHAN _IOW('t', 56, int) /* attach to ppp channel */
> #define PPPIOCGCHAN _IOR('t', 55, int) /* get ppp channel number */
> #define PPPIOCGL2TPSTATS _IOR('t', 54, struct pppol2tp_ioc_stats)
> +#define PPPIOCBRIDGECHAN _IOW('t', 53, int) /* bridge one channel to another */
>
> #define SIOCGPPPSTATS (SIOCDEVPRIVATE + 0)
> #define SIOCGPPPVER (SIOCDEVPRIVATE + 1) /* NEVER change this!! */
> --
> 2.17.1
>
next prev parent reply other threads:[~2020-11-09 23:24 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-06 18:16 [RFC PATCH 0/2] add ppp_generic ioctl to bridge channels Tom Parkin
2020-11-06 18:16 ` [RFC PATCH 1/2] ppp: add PPPIOCBRIDGECHAN ioctl Tom Parkin
2020-11-09 23:24 ` Guillaume Nault [this message]
2020-11-10 12:04 ` Tom Parkin
2020-11-15 16:28 ` Guillaume Nault
2020-11-17 12:26 ` Tom Parkin
2020-11-17 14:06 ` Guillaume Nault
2020-11-06 18:16 ` [RFC PATCH 2/2] docs: update ppp_generic.rst to describe ioctl PPPIOCBRIDGECHAN Tom Parkin
2020-11-09 22:51 ` [RFC PATCH 0/2] add ppp_generic ioctl to bridge channels Guillaume Nault
2020-11-10 11:54 ` Tom Parkin
2020-11-15 11:59 ` Guillaume Nault
2020-11-17 12:12 ` Tom Parkin
2020-11-09 23:52 ` Jakub Kicinski
2020-11-10 9:28 ` Guillaume Nault
2020-11-10 12:42 ` Tom Parkin
2020-11-10 15:02 ` Guillaume Nault
2020-11-10 16:47 ` Jakub Kicinski
2020-11-17 12:54 ` Tom Parkin
2020-11-17 14:17 ` Guillaume Nault
2020-11-17 16:52 ` Jakub Kicinski
2020-11-18 20:24 ` Guillaume Nault
2020-11-20 1:17 ` Jakub Kicinski
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=20201109232401.GM2366@linux.home \
--to=gnault@redhat.com \
--cc=jchapman@katalix.com \
--cc=netdev@vger.kernel.org \
--cc=tparkin@katalix.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.