| Message ID | 20201210155058.14518-1-tparkin@katalix.com |
|---|---|
| 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 :-)
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(-)