| Message ID | c64284f4-2c2a-ecb9-a08e-9e49d49c720b@I-love.SAKURA.ne.jp (mailing list archive) |
|---|---|
| State | Not Applicable |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [6.1-rc6] l2tp: call udp_tunnel_encap_enable() and sock_release() without sk_callback_lock | expand |
On Fri, Nov 18, 2022 at 3:51 AM Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote: > > syzbot is reporting sleep in atomic context at l2tp_tunnel_register() [1], > for commit b68777d54fac ("l2tp: Serialize access to sk_user_data with > sk_callback_lock") missed that udp_tunnel_encap_enable() from > setup_udp_tunnel_sock() might sleep. > > Since we don't want to drop sk->sk_callback_lock inside > setup_udp_tunnel_sock() right before calling udp_tunnel_encap_enable(), > introduce a variant which does not call udp_tunnel_encap_enable(). And > call udp_tunnel_encap_enable() after dropping sk->sk_callback_lock. > > Also, drop sk->sk_callback_lock before calling sock_release() in order to > avoid circular locking dependency problem. Please look at recent discussion, your patch does not address another fundamental problem. Also, Jakub was working on a fix already. Perhaps sync with him to avoid duplicate work. https://lore.kernel.org/netdev/20221114191619.124659-1-jakub@cloudflare.com/T/ Thanks.
On 2022/11/18 21:36, Eric Dumazet wrote: > Please look at recent discussion, your patch does not address another > fundamental problem. > > Also, Jakub was working on a fix already. Perhaps sync with him to > avoid duplicate work. I can't afford monitoring all mailing lists. Since a thread at syzkaller-bugs group did not get that information, I started this work. Please consider including syzbot+XXXXXXXXXXXXXXXXXXXX@syzkaller.appspotmail.com into the discussions so that we can google for recent discussions (if any) using mail address as a keyword. > > https://lore.kernel.org/netdev/20221114191619.124659-1-jakub@cloudflare.com/T/ > > Thanks.
On Fri, Nov 18, 2022 at 5:19 AM Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote: > > On 2022/11/18 21:36, Eric Dumazet wrote: > > Please look at recent discussion, your patch does not address another > > fundamental problem. > > > > Also, Jakub was working on a fix already. Perhaps sync with him to > > avoid duplicate work. > > I can't afford monitoring all mailing lists. Since a thread at syzkaller-bugs group > did not get that information, I started this work. Please consider including > syzbot+XXXXXXXXXXXXXXXXXXXX@syzkaller.appspotmail.com into the discussions so that > we can google for recent discussions (if any) using mail address as a keyword. > This is not going to happen. The discussion happened before the reports were made public. No more than 7 syzbot reports are attached to the same root cause. We deal with hundreds of syzbot reports per week, there is no way we can retroactively find all relevant netdev@ threads. If you can not afford making sure you are not wasting your time, this is your call.
On Fri, Nov 18, 2022 at 04:36 AM -08, Eric Dumazet wrote: > On Fri, Nov 18, 2022 at 3:51 AM Tetsuo Handa > <penguin-kernel@i-love.sakura.ne.jp> wrote: >> >> syzbot is reporting sleep in atomic context at l2tp_tunnel_register() [1], >> for commit b68777d54fac ("l2tp: Serialize access to sk_user_data with >> sk_callback_lock") missed that udp_tunnel_encap_enable() from >> setup_udp_tunnel_sock() might sleep. >> >> Since we don't want to drop sk->sk_callback_lock inside >> setup_udp_tunnel_sock() right before calling udp_tunnel_encap_enable(), >> introduce a variant which does not call udp_tunnel_encap_enable(). And >> call udp_tunnel_encap_enable() after dropping sk->sk_callback_lock. >> >> Also, drop sk->sk_callback_lock before calling sock_release() in order to >> avoid circular locking dependency problem. > > Please look at recent discussion, your patch does not address another > fundamental problem. > > Also, Jakub was working on a fix already. Perhaps sync with him to > avoid duplicate work. > > https://lore.kernel.org/netdev/20221114191619.124659-1-jakub@cloudflare.com/T/ > > Thanks. Thanks for the patch, Tetsuo. As Eric has pointed out [1], there is another problem - in addition to sleeping in atomic context, I have also failed to use the write_lock variant which disabled BH locally. The latter bug can lead to dead-locks, as reported by syzcaller [2, 3], because we grab sk_callback_lock in softirq context, which can then block waiting on us if: 1) it runs on the same CPU, or CPU0 ---- lock(clock-AF_INET6); <Interrupt> lock(clock-AF_INET6); 2) lock ordering leads to priority inversion CPU0 CPU1 ---- ---- lock(clock-AF_INET6); local_irq_disable(); lock(&tcp_hashinfo.bhash[i].lock); lock(clock-AF_INET6); <Interrupt> lock(&tcp_hashinfo.bhash[i].lock); IOW, your patch works if we also s/write_\(un\)\?lock/write_\1lock_bh/. But, I also have an alternative idea - instead of pulling the function call that might sleep out of the critical section, I think we can make the critical section much shorter by rearranging the tunnel initialization code slightly. That is, a change like below. -jkbs [1] https://lore.kernel.org/netdev/CANn89iLQUZnyGNCn2GpW31FXpE_Lt7a5Urr21RqzfAE4sYxs+w@mail.gmail.com/ [2] https://lore.kernel.org/netdev/000000000000e38b6605eda76f98@google.com [3] https://lore.kernel.org/netdev/000000000000dfa31e05eda76f75@google.com/ --8<-- diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c index 754fdda8a5f5..07454c0418e3 100644 --- a/net/l2tp/l2tp_core.c +++ b/net/l2tp/l2tp_core.c @@ -1474,11 +1474,15 @@ int l2tp_tunnel_register(struct l2tp_tunnel *tunnel, struct net *net, } sk = sock->sk; - write_lock(&sk->sk_callback_lock); + write_lock_bh(&sk->sk_callback_lock); ret = l2tp_validate_socket(sk, net, tunnel->encap); if (ret < 0) goto err_sock; + if (tunnel->encap != L2TP_ENCAPTYPE_UDP) + rcu_assign_sk_user_data(sk, tunnel); + + write_unlock_bh(&sk->sk_callback_lock); tunnel->l2tp_net = net; pn = l2tp_pernet(net); @@ -1507,8 +1511,6 @@ int l2tp_tunnel_register(struct l2tp_tunnel *tunnel, struct net *net, }; setup_udp_tunnel_sock(net, sock, &udp_cfg); - } else { - rcu_assign_sk_user_data(sk, tunnel); } tunnel->old_sk_destruct = sk->sk_destruct; @@ -1522,7 +1524,6 @@ int l2tp_tunnel_register(struct l2tp_tunnel *tunnel, struct net *net, if (tunnel->fd >= 0) sockfd_put(sock); - write_unlock(&sk->sk_callback_lock); return 0; err_sock: @@ -1530,8 +1531,6 @@ int l2tp_tunnel_register(struct l2tp_tunnel *tunnel, struct net *net, sock_release(sock); else sockfd_put(sock); - - write_unlock(&sk->sk_callback_lock); err: return ret; }
On Fri, Nov 18, 2022 at 06:50 PM +01, Jakub Sitnicki wrote: [...] > But, I also have an alternative idea - instead of pulling the function > call that might sleep out of the critical section, I think we could make > the critical section much shorter by rearranging the tunnel > initialization code slightly. That is, a change like below. [...] > --8<-- > > diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c > index 754fdda8a5f5..07454c0418e3 100644 > --- a/net/l2tp/l2tp_core.c > +++ b/net/l2tp/l2tp_core.c > @@ -1474,11 +1474,15 @@ int l2tp_tunnel_register(struct l2tp_tunnel *tunnel, struct net *net, > } > > sk = sock->sk; > - write_lock(&sk->sk_callback_lock); > + write_lock_bh(&sk->sk_callback_lock); > > ret = l2tp_validate_socket(sk, net, tunnel->encap); > if (ret < 0) > goto err_sock; > + if (tunnel->encap != L2TP_ENCAPTYPE_UDP) > + rcu_assign_sk_user_data(sk, tunnel); sk_user_data needs to be reset back to NULL if we bail out when the tunnel already exists. Will add that and turn it into a patch tomorrow. > + > + write_unlock_bh(&sk->sk_callback_lock); > > tunnel->l2tp_net = net; > pn = l2tp_pernet(net); > @@ -1507,8 +1511,6 @@ int l2tp_tunnel_register(struct l2tp_tunnel *tunnel, struct net *net, > }; > > setup_udp_tunnel_sock(net, sock, &udp_cfg); > - } else { > - rcu_assign_sk_user_data(sk, tunnel); > } > > tunnel->old_sk_destruct = sk->sk_destruct; > @@ -1522,7 +1524,6 @@ int l2tp_tunnel_register(struct l2tp_tunnel *tunnel, struct net *net, > if (tunnel->fd >= 0) > sockfd_put(sock); > > - write_unlock(&sk->sk_callback_lock); > return 0; > > err_sock: > @@ -1530,8 +1531,6 @@ int l2tp_tunnel_register(struct l2tp_tunnel *tunnel, struct net *net, > sock_release(sock); > else > sockfd_put(sock); > - > - write_unlock(&sk->sk_callback_lock); > err: > return ret; > }
On 2022/11/19 2:50, Jakub Sitnicki wrote: > Thanks for the patch, Tetsuo. > > As Eric has pointed out [1], there is another problem - in addition to > sleeping in atomic context, I have also failed to use the write_lock > variant which disabled BH locally. > > The latter bug can lead to dead-locks, as reported by syzcaller [2, 3], > because we grab sk_callback_lock in softirq context, which can then > block waiting on us if: Below is another approach I was thinking of, for reusing existing locks is prone to locking bugs like [2] and [3]. I couldn't interpret "Write-protected by @sk_callback_lock." part because it does not say what lock is needed for protecting sk_user_data for read access. Is it possible to use a mutex dedicated for l2tp_tunnel_destruct() (and optionally setup_udp_tunnel_sock_no_enable() in order not to create l2tp_tunnel_register_mutex => cpu_hotplug_lock chain) ? By the way I haven't heard an response on Since userspace-supplied file descriptor has to be a datagram socket, can we somehow copy the source/destination addresses from userspace-supplied socket to kernel-created socket? at https://lkml.kernel.org/r/c9695548-3f27-dda1-3124-ec21da106741@I-love.SAKURA.ne.jp (that is, always create a new socket in order to be able to assign lockdep class before that socket is used). diff --git a/include/net/sock.h b/include/net/sock.h index e0517ecc6531..49473013afa6 100644 --- a/include/net/sock.h +++ b/include/net/sock.h @@ -323,7 +323,7 @@ struct sk_filter; * @sk_tskey: counter to disambiguate concurrent tstamp requests * @sk_zckey: counter to order MSG_ZEROCOPY notifications * @sk_socket: Identd and reporting IO signals - * @sk_user_data: RPC layer private data. Write-protected by @sk_callback_lock. + * @sk_user_data: RPC layer private data. * @sk_frag: cached page frag * @sk_peek_off: current peek_offset value * @sk_send_head: front of stuff to transmit diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c index 754fdda8a5f5..2bfcf6968d89 100644 --- a/net/l2tp/l2tp_core.c +++ b/net/l2tp/l2tp_core.c @@ -1150,10 +1150,8 @@ static void l2tp_tunnel_destruct(struct sock *sk) } /* Remove hooks into tunnel socket */ - write_lock_bh(&sk->sk_callback_lock); sk->sk_destruct = tunnel->old_sk_destruct; sk->sk_user_data = NULL; - write_unlock_bh(&sk->sk_callback_lock); /* Call the original destructor */ if (sk->sk_destruct) @@ -1455,6 +1453,7 @@ static int l2tp_validate_socket(const struct sock *sk, const struct net *net, int l2tp_tunnel_register(struct l2tp_tunnel *tunnel, struct net *net, struct l2tp_tunnel_cfg *cfg) { + static DEFINE_MUTEX(l2tp_tunnel_register_mutex); struct l2tp_tunnel *tunnel_walk; struct l2tp_net *pn; struct socket *sock; @@ -1474,7 +1473,7 @@ int l2tp_tunnel_register(struct l2tp_tunnel *tunnel, struct net *net, } sk = sock->sk; - write_lock(&sk->sk_callback_lock); + mutex_lock(&l2tp_tunnel_register_mutex); ret = l2tp_validate_socket(sk, net, tunnel->encap); if (ret < 0) @@ -1519,19 +1518,18 @@ int l2tp_tunnel_register(struct l2tp_tunnel *tunnel, struct net *net, trace_register_tunnel(tunnel); + mutex_unlock(&l2tp_tunnel_register_mutex); if (tunnel->fd >= 0) sockfd_put(sock); - write_unlock(&sk->sk_callback_lock); return 0; err_sock: + mutex_unlock(&l2tp_tunnel_register_mutex); if (tunnel->fd < 0) sock_release(sock); else sockfd_put(sock); - - write_unlock(&sk->sk_callback_lock); err: return ret; }
On Sat, Nov 19, 2022 at 07:08 PM +09, Tetsuo Handa wrote: > On 2022/11/19 2:50, Jakub Sitnicki wrote: >> Thanks for the patch, Tetsuo. >> >> As Eric has pointed out [1], there is another problem - in addition to >> sleeping in atomic context, I have also failed to use the write_lock >> variant which disabled BH locally. >> >> The latter bug can lead to dead-locks, as reported by syzcaller [2, 3], >> because we grab sk_callback_lock in softirq context, which can then >> block waiting on us if: > > Below is another approach I was thinking of, for reusing existing locks is prone > to locking bugs like [2] and [3]. > > I couldn't interpret "Write-protected by @sk_callback_lock." part because > it does not say what lock is needed for protecting sk_user_data for read access. sk_user_data is RCU-protected on reader-side. But we still need to synchronize writers. > Is it possible to use a mutex dedicated for l2tp_tunnel_destruct() (and optionally > setup_udp_tunnel_sock_no_enable() in order not to create l2tp_tunnel_register_mutex => > cpu_hotplug_lock chain) ? No, we need to a common lock to synchronize with other users in the net stack (reuseport groups, sockmap/psock to name a couple). > By the way I haven't heard an response on > > Since userspace-supplied file descriptor has to be a datagram socket, > can we somehow copy the source/destination addresses from > userspace-supplied socket to kernel-created socket? > > at https://lkml.kernel.org/r/c9695548-3f27-dda1-3124-ec21da106741@I-love.SAKURA.ne.jp > (that is, always create a new socket in order to be able to assign lockdep class > before that socket is used). This is a drive by fix for me to l2tp, so I might not be the best person to ask, but I will take a look at the thread. [...]
diff --git a/include/net/udp_tunnel.h b/include/net/udp_tunnel.h index 72394f441dad..a84fa57bc750 100644 --- a/include/net/udp_tunnel.h +++ b/include/net/udp_tunnel.h @@ -92,6 +92,8 @@ struct udp_tunnel_sock_cfg { /* Setup the given (UDP) sock to receive UDP encapsulated packets */ void setup_udp_tunnel_sock(struct net *net, struct socket *sock, struct udp_tunnel_sock_cfg *sock_cfg); +void setup_udp_tunnel_sock_no_enable(struct net *net, struct socket *sock, + struct udp_tunnel_sock_cfg *sock_cfg); /* -- List of parsable UDP tunnel types -- * diff --git a/net/ipv4/udp_tunnel_core.c b/net/ipv4/udp_tunnel_core.c index 8242c8947340..dff825664000 100644 --- a/net/ipv4/udp_tunnel_core.c +++ b/net/ipv4/udp_tunnel_core.c @@ -57,8 +57,8 @@ int udp_sock_create4(struct net *net, struct udp_port_cfg *cfg, } EXPORT_SYMBOL(udp_sock_create4); -void setup_udp_tunnel_sock(struct net *net, struct socket *sock, - struct udp_tunnel_sock_cfg *cfg) +void setup_udp_tunnel_sock_no_enable(struct net *net, struct socket *sock, + struct udp_tunnel_sock_cfg *cfg) { struct sock *sk = sock->sk; @@ -77,7 +77,13 @@ void setup_udp_tunnel_sock(struct net *net, struct socket *sock, udp_sk(sk)->encap_destroy = cfg->encap_destroy; udp_sk(sk)->gro_receive = cfg->gro_receive; udp_sk(sk)->gro_complete = cfg->gro_complete; +} +EXPORT_SYMBOL_GPL(setup_udp_tunnel_sock_no_enable); +void setup_udp_tunnel_sock(struct net *net, struct socket *sock, + struct udp_tunnel_sock_cfg *cfg) +{ + setup_udp_tunnel_sock_no_enable(net, sock, cfg); udp_tunnel_encap_enable(sock); } EXPORT_SYMBOL_GPL(setup_udp_tunnel_sock); diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c index 754fdda8a5f5..a4f611196c83 100644 --- a/net/l2tp/l2tp_core.c +++ b/net/l2tp/l2tp_core.c @@ -1506,7 +1506,7 @@ int l2tp_tunnel_register(struct l2tp_tunnel *tunnel, struct net *net, .encap_destroy = l2tp_udp_encap_destroy, }; - setup_udp_tunnel_sock(net, sock, &udp_cfg); + setup_udp_tunnel_sock_no_enable(net, sock, &udp_cfg); } else { rcu_assign_sk_user_data(sk, tunnel); } @@ -1519,19 +1519,19 @@ int l2tp_tunnel_register(struct l2tp_tunnel *tunnel, struct net *net, trace_register_tunnel(tunnel); + write_unlock(&sk->sk_callback_lock); + if (tunnel->encap == L2TP_ENCAPTYPE_UDP) + udp_tunnel_encap_enable(sock); if (tunnel->fd >= 0) sockfd_put(sock); - - write_unlock(&sk->sk_callback_lock); return 0; err_sock: + write_unlock(&sk->sk_callback_lock); if (tunnel->fd < 0) sock_release(sock); else sockfd_put(sock); - - write_unlock(&sk->sk_callback_lock); err: return ret; }
syzbot is reporting sleep in atomic context at l2tp_tunnel_register() [1], for commit b68777d54fac ("l2tp: Serialize access to sk_user_data with sk_callback_lock") missed that udp_tunnel_encap_enable() from setup_udp_tunnel_sock() might sleep. Since we don't want to drop sk->sk_callback_lock inside setup_udp_tunnel_sock() right before calling udp_tunnel_encap_enable(), introduce a variant which does not call udp_tunnel_encap_enable(). And call udp_tunnel_encap_enable() after dropping sk->sk_callback_lock. Also, drop sk->sk_callback_lock before calling sock_release() in order to avoid circular locking dependency problem. Link: https://syzkaller.appspot.com/bug?extid=703d9e154b3b58277261 [1] Reported-by: syzbot <syzbot+703d9e154b3b58277261@syzkaller.appspotmail.com> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Fixes: b68777d54fac ("l2tp: Serialize access to sk_user_data with sk_callback_lock") --- F.Y.I. Below is the lockdep message: ====================================================== WARNING: possible circular locking dependency detected 6.1.0-rc5+ #2 Not tainted ------------------------------------------------------ a.out/2794 is trying to acquire lock: ffff8c628878bdf0 (k-sk_lock-AF_INET){+.+.}-{0:0}, at: sk_common_release+0x19/0xe0 but task is already holding lock: ffff8c628878c078 (k-clock-AF_INET){+++.}-{2:2}, at: l2tp_tunnel_register+0x64/0x5e0 [l2tp_core] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (k-clock-AF_INET){+++.}-{2:2}: lock_acquire+0xc7/0x2e0 _raw_read_lock_bh+0x3d/0x80 sock_i_uid+0x19/0x40 udp_lib_lport_inuse+0x2c/0x120 udp_lib_get_port+0xf8/0x570 udp_v4_get_port+0xbb/0xc0 __inet_bind+0x10e/0x240 inet_bind+0x2b/0x40 kernel_bind+0xb/0x10 udp_sock_create4+0x97/0x160 [udp_tunnel] l2tp_tunnel_sock_create+0x316/0x330 [l2tp_core] l2tp_tunnel_register+0x394/0x5e0 [l2tp_core] l2tp_nl_cmd_tunnel_create+0xe8/0x200 [l2tp_netlink] genl_family_rcv_msg_doit.isra.17+0x102/0x140 genl_rcv_msg+0x112/0x270 netlink_rcv_skb+0x4f/0x100 genl_rcv+0x23/0x40 netlink_unicast+0x1a5/0x280 netlink_sendmsg+0x22f/0x490 sock_sendmsg+0x2e/0x40 ____sys_sendmsg+0x1e9/0x210 ___sys_sendmsg+0x77/0xb0 __sys_sendmsg+0x60/0xb0 __x64_sys_sendmsg+0x1a/0x20 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd -> #1 (&table->hash[i].lock){+...}-{2:2}: lock_acquire+0xc7/0x2e0 _raw_spin_lock_bh+0x31/0x40 udp_lib_get_port+0xda/0x570 udp_v4_get_port+0xbb/0xc0 __inet_bind+0x10e/0x240 inet_bind+0x2b/0x40 kernel_bind+0xb/0x10 udp_sock_create4+0x97/0x160 [udp_tunnel] l2tp_tunnel_sock_create+0x316/0x330 [l2tp_core] l2tp_tunnel_register+0x394/0x5e0 [l2tp_core] l2tp_nl_cmd_tunnel_create+0xe8/0x200 [l2tp_netlink] genl_family_rcv_msg_doit.isra.17+0x102/0x140 genl_rcv_msg+0x112/0x270 netlink_rcv_skb+0x4f/0x100 genl_rcv+0x23/0x40 netlink_unicast+0x1a5/0x280 netlink_sendmsg+0x22f/0x490 sock_sendmsg+0x2e/0x40 ____sys_sendmsg+0x1e9/0x210 ___sys_sendmsg+0x77/0xb0 __sys_sendmsg+0x60/0xb0 __x64_sys_sendmsg+0x1a/0x20 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd -> #0 (k-sk_lock-AF_INET){+.+.}-{0:0}: check_prevs_add+0x16a/0x1070 __lock_acquire+0x11bd/0x1670 lock_acquire+0xc7/0x2e0 udp_destroy_sock+0x2d/0xd0 sk_common_release+0x19/0xe0 udp_lib_close+0x9/0x10 inet_release+0x2e/0x60 __sock_release+0x7e/0xa0 sock_release+0xb/0x10 l2tp_tunnel_register+0x3f1/0x5e0 [l2tp_core] l2tp_nl_cmd_tunnel_create+0xe8/0x200 [l2tp_netlink] genl_family_rcv_msg_doit.isra.17+0x102/0x140 genl_rcv_msg+0x112/0x270 netlink_rcv_skb+0x4f/0x100 genl_rcv+0x23/0x40 netlink_unicast+0x1a5/0x280 netlink_sendmsg+0x22f/0x490 sock_sendmsg+0x2e/0x40 ____sys_sendmsg+0x1e9/0x210 ___sys_sendmsg+0x77/0xb0 __sys_sendmsg+0x60/0xb0 __x64_sys_sendmsg+0x1a/0x20 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd other info that might help us debug this: Chain exists of: k-sk_lock-AF_INET --> &table->hash[i].lock --> k-clock-AF_INET Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(k-clock-AF_INET); lock(&table->hash[i].lock); lock(k-clock-AF_INET); lock(k-sk_lock-AF_INET); *** DEADLOCK *** 3 locks held by a.out/2794: #0: ffffffffb466fc30 (cb_lock){++++}-{3:3}, at: genl_rcv+0x14/0x40 #1: ffffffffb466fcc8 (genl_mutex){+.+.}-{3:3}, at: genl_rcv_msg+0x14d/0x270 #2: ffff8c628878c078 (k-clock-AF_INET){+++.}-{2:2}, at: l2tp_tunnel_register+0x64/0x5e0 [l2tp_core] include/net/udp_tunnel.h | 2 ++ net/ipv4/udp_tunnel_core.c | 10 ++++++++-- net/l2tp/l2tp_core.c | 10 +++++----- 3 files changed, 15 insertions(+), 7 deletions(-)