From: Gao Feng <redacted>
In the commit ddab82821fa6 ("ppp: Fix a scheduling-while-atomic bug in
del_chan"), I moved the synchronize_rcu() from del_chan() to pptp_release
after del_chan() to avoid one scheduling-while-atomic bug.
Actually the del_chan() and pppox_unbind_sock are unneccessary in the
pptp_sock_destruct. Because the pptp sock refcnt wouldn't reach zero until
sk_state is set as PPPOX_DEAD in pptp_release. By that time, the del_chan()
and pppox_unbind_sock() have been invoked already and the condition check
"!(sk->sk_state & PPPOX_DEAD)" of this sock must be false in pptp_sock_destruct.
So we could remove these statements in pptp_sock_destruct, and then restore
the synchronize_rcu() into del_chan.
Signed-off-by: Gao Feng <redacted>
---
drivers/net/ppp/pptp.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/net/ppp/pptp.c b/drivers/net/ppp/pptp.c
index 6dde9a0..8632e1a 100644
--- a/drivers/net/ppp/pptp.c
+++ b/drivers/net/ppp/pptp.c
@@ -131,6 +131,7 @@ static void del_chan(struct pppox_sock *sock)
clear_bit(sock->proto.pptp.src_addr.call_id, callid_bitmap);
RCU_INIT_POINTER(callid_sock[sock->proto.pptp.src_addr.call_id], NULL);
spin_unlock(&chan_lock);
+ synchronize_rcu();
}
static int pptp_xmit(struct ppp_channel *chan, struct sk_buff *skb)
@@ -519,7 +520,6 @@ static int pptp_release(struct socket *sock)
po = pppox_sk(sk);
del_chan(po);
- synchronize_rcu();
pppox_unbind_sock(sk);
sk->sk_state = PPPOX_DEAD;
@@ -535,10 +535,6 @@ static int pptp_release(struct socket *sock)
static void pptp_sock_destruct(struct sock *sk)
{
- if (!(sk->sk_state & PPPOX_DEAD)) {
- del_chan(pppox_sk(sk));
- pppox_unbind_sock(sk);
- }
skb_queue_purge(&sk->sk_receive_queue);
}
--
1.9.1
On Wed, Aug 9, 2017 at 8:57 AM, [off-list ref] wrote:
From: Gao Feng <redacted>
In the commit ddab82821fa6 ("ppp: Fix a scheduling-while-atomic bug in
del_chan"), I moved the synchronize_rcu() from del_chan() to pptp_release
after del_chan() to avoid one scheduling-while-atomic bug.
Actually the del_chan() and pppox_unbind_sock are unneccessary in the
pptp_sock_destruct. Because the pptp sock refcnt wouldn't reach zero until
sk_state is set as PPPOX_DEAD in pptp_release. By that time, the del_chan()
and pppox_unbind_sock() have been invoked already and the condition check
"!(sk->sk_state & PPPOX_DEAD)" of this sock must be false in pptp_sock_destruct.
I am not sure. The check for sock->sk in the beginning of pptp_release()
indicates there could be a case we could skip del_chan() in pptp_release(),
although I can't figure out how.
Also there is a suspicious sock_put() in pptp_release().
At 2017-08-10 02:08:30, "Cong Wang" [off-list ref] wrote:
On Wed, Aug 9, 2017 at 8:57 AM, [off-list ref] wrote:
quoted
From: Gao Feng <redacted>
In the commit ddab82821fa6 ("ppp: Fix a scheduling-while-atomic bug in
del_chan"), I moved the synchronize_rcu() from del_chan() to pptp_release
after del_chan() to avoid one scheduling-while-atomic bug.
Actually the del_chan() and pppox_unbind_sock are unneccessary in the
pptp_sock_destruct. Because the pptp sock refcnt wouldn't reach zero until
sk_state is set as PPPOX_DEAD in pptp_release. By that time, the del_chan()
and pppox_unbind_sock() have been invoked already and the condition check
"!(sk->sk_state & PPPOX_DEAD)" of this sock must be false in pptp_sock_destruct.
I am not sure. The check for sock->sk in the beginning of pptp_release()
indicates there could be a case we could skip del_chan() in pptp_release(),
although I can't figure out how.
Also there is a suspicious sock_put() in pptp_release().
Hi Cong,
Thank you. I also failed to find the case which causes the sock->sk is null in release().
There is a suspicious case in __sock_create following.
err = pf->create(net, sock, protocol, kern);
if (err < 0)
goto out_module_put;
.......
out_module_put:
sock->ops = NULL;
module_put(pf->owner);
out_sock_release:
sock_release(sock);
return err;
In the beginning, I thought when create is failed and the sock->sk is null, then the sock_release is invoked.
It could cause the sk is null in the release().
But I find it has already reset the sock->ops as NULL before sock_release later, so the release() wouldn't be invoked actually.
Best Regards
Feng