| 123456789101112131415161718192021222324252627282930313233343536373839404142434445 |
- From: Guillaume Nault <g.nault@alphalink.fr>
- Date: Thu, 19 Nov 2015 12:52:56 +0100
- Subject: [PATCH] ppp: don't set sk_state to PPPOX_ZOMBIE in pppoe_disc_rcv()
- Since 287f3a943fef ("pppoe: Use workqueue to die properly when a PADT
- is received"), pppoe_disc_rcv() disconnects the socket by scheduling
- pppoe_unbind_sock_work(). This is enough to stop socket transmission
- and makes the PPPOX_ZOMBIE state uncessary.
- Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
- Signed-off-by: David S. Miller <davem@davemloft.net>
- ---
- --- a/drivers/net/ppp/pppoe.c
- +++ b/drivers/net/ppp/pppoe.c
- @@ -500,27 +500,9 @@ static int pppoe_disc_rcv(struct sk_buff
-
- pn = pppoe_pernet(dev_net(dev));
- po = get_item(pn, ph->sid, eth_hdr(skb)->h_source, dev->ifindex);
- - if (po) {
- - struct sock *sk = sk_pppox(po);
- -
- - bh_lock_sock(sk);
- -
- - /* If the user has locked the socket, just ignore
- - * the packet. With the way two rcv protocols hook into
- - * one socket family type, we cannot (easily) distinguish
- - * what kind of SKB it is during backlog rcv.
- - */
- - if (sock_owned_by_user(sk) == 0) {
- - /* We're no longer connect at the PPPOE layer,
- - * and must wait for ppp channel to disconnect us.
- - */
- - sk->sk_state = PPPOX_ZOMBIE;
- - }
- -
- - bh_unlock_sock(sk);
- + if (po)
- if (!schedule_work(&po->proto.pppoe.padt_work))
- - sock_put(sk);
- - }
- + sock_put(sk_pppox(po));
-
- abort:
- kfree_skb(skb);
|
