| Message ID | 20201210155058.14518-1-tparkin@katalix.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | add ppp_generic ioctl(s) to bridge channels | expand |
On Thu, Dec 10, 2020 at 03:50:56PM +0000, Tom Parkin wrote: > Following on from my previous RFC[1], this series adds two ioctl calls > to the ppp code to implement "channel bridging". > > When two ppp channels are bridged, frames presented to ppp_input() on > one channel are passed to the other channel's ->start_xmit function for > transmission. > > The primary use-case for this functionality is in an L2TP Access > Concentrator where PPP frames are typically presented in a PPPoE session > (e.g. from a home broadband user) and are forwarded to the ISP network in > a PPPoL2TP session. Looks good to me now. Thanks Tom! Reviewed-by: Guillaume Nault <gnault@redhat.com>
On Thu, Dec 10, 2020 at 18:13:09 +0100, Guillaume Nault wrote: > On Thu, Dec 10, 2020 at 03:50:56PM +0000, Tom Parkin wrote: > > Following on from my previous RFC[1], this series adds two ioctl calls > > to the ppp code to implement "channel bridging". > > > > When two ppp channels are bridged, frames presented to ppp_input() on > > one channel are passed to the other channel's ->start_xmit function for > > transmission. > > > > The primary use-case for this functionality is in an L2TP Access > > Concentrator where PPP frames are typically presented in a PPPoE session > > (e.g. from a home broadband user) and are forwarded to the ISP network in > > a PPPoL2TP session. > > Looks good to me now. Thanks Tom! > > Reviewed-by: Guillaume Nault <gnault@redhat.com> > Thanks again for your review and help with the series :-)
From: Tom Parkin <tparkin@katalix.com> Date: Thu, 10 Dec 2020 17:16:45 +0000 > On Thu, Dec 10, 2020 at 18:13:09 +0100, Guillaume Nault wrote: >> On Thu, Dec 10, 2020 at 03:50:56PM +0000, Tom Parkin wrote: >> > Following on from my previous RFC[1], this series adds two ioctl calls >> > to the ppp code to implement "channel bridging". >> > >> > When two ppp channels are bridged, frames presented to ppp_input() on >> > one channel are passed to the other channel's ->start_xmit function for >> > transmission. >> > >> > The primary use-case for this functionality is in an L2TP Access >> > Concentrator where PPP frames are typically presented in a PPPoE session >> > (e.g. from a home broadband user) and are forwarded to the ISP network in >> > a PPPoL2TP session. >> >> Looks good to me now. Thanks Tom! >> >> Reviewed-by: Guillaume Nault <gnault@redhat.com> >> > > Thanks again for your review and help with the series :-) Series applied.
On Thu, Dec 10, 2020 at 14:21:34 -0800, David Miller wrote: > From: Tom Parkin <tparkin@katalix.com> > Date: Thu, 10 Dec 2020 17:16:45 +0000 > > > On Thu, Dec 10, 2020 at 18:13:09 +0100, Guillaume Nault wrote: > >> On Thu, Dec 10, 2020 at 03:50:56PM +0000, Tom Parkin wrote: > >> > Following on from my previous RFC[1], this series adds two ioctl calls > >> > to the ppp code to implement "channel bridging". > >> > > >> > When two ppp channels are bridged, frames presented to ppp_input() on > >> > one channel are passed to the other channel's ->start_xmit function for > >> > transmission. > >> > > >> > The primary use-case for this functionality is in an L2TP Access > >> > Concentrator where PPP frames are typically presented in a PPPoE session > >> > (e.g. from a home broadband user) and are forwarded to the ISP network in > >> > a PPPoL2TP session. > >> > >> Looks good to me now. Thanks Tom! > >> > >> Reviewed-by: Guillaume Nault <gnault@redhat.com> > >> > > > > Thanks again for your review and help with the series :-) > > Series applied. Thanks Dave. Nice to see you back :-)
Following on from my previous RFC[1], this series adds two ioctl calls to the ppp code to implement "channel bridging". When two ppp channels are bridged, frames presented to ppp_input() on one channel are passed to the other channel's ->start_xmit function for transmission. The primary use-case for this functionality is in an L2TP Access Concentrator where PPP frames are typically presented in a PPPoE session (e.g. from a home broadband user) and are forwarded to the ISP network in a PPPoL2TP session. The two new ioctls, PPPIOCBRIDGECHAN and PPPIOCUNBRIDGECHAN form a symmetric pair. Userspace code testing and illustrating use of the ioctl calls is available in the go-l2tp[2] and l2tp-ktest[3] repositories. [1]. Previous RFC series: https://lore.kernel.org/netdev/20201106181647.16358-1-tparkin@katalix.com/ [2]. go-l2tp: a Go library for building L2TP applications on Linux systems. Support for the PPPIOCBRIDGECHAN ioctl is on a branch: https://github.com/katalix/go-l2tp/tree/tp_002_pppoe_2 [3]. l2tp-ktest: a test suite for the Linux Kernel L2TP subsystem. Support for the PPPIOCBRIDGECHAN ioctl is on a branch: https://github.com/katalix/l2tp-ktest/tree/tp_ac_pppoe_tests_2 Changelog: v4: * Fix NULL-pointer access in PPPIOCBRIDGECHAN in the case that the ID of the channel to be bridged wasn't found. * Add comment in ppp_unbridge_channels to better document the unbridge process. v3: * Use rcu_dereference_protected for accessing struct channel 'bridge' field during updates with lock 'upl' held. * Avoid race in ppp_unbridge_channels by ensuring that each channel in the bridge points to it's peer before decrementing refcounts. v2: * Add missing __rcu annotation to struct channel 'bridge' field in order to squash a sparse warning from a C=1 build * Integrate review comments from gnault@redhat.com * Have ppp_unbridge_channels return -EINVAL if the channel isn't part of a bridge: this better aligns with the return code from ppp_disconnect_channel. * Improve docs update by including information on ioctl arguments and error return codes. Tom Parkin (2): ppp: add PPPIOCBRIDGECHAN and PPPIOCUNBRIDGECHAN ioctls docs: update ppp_generic.rst to document new ioctls Documentation/networking/ppp_generic.rst | 16 +++ drivers/net/ppp/ppp_generic.c | 152 ++++++++++++++++++++++- include/uapi/linux/ppp-ioctl.h | 2 + 3 files changed, 167 insertions(+), 3 deletions(-)