* [Q] why do we ever try to call unix_dgram_peer_wake_disconnect() for SOCK_STREAM?
@ 2019-02-24 6:28 Al Viro
0 siblings, 0 replies; only message in thread
From: Al Viro @ 2019-02-24 6:28 UTC (permalink / raw)
To: netdev; +Cc: Rainer Weikusat
What's the point of calling unix_dgram_peer_wake_disconnect() in
unix_release_sock() of SOCK_STREAM/SOCK_SEQPACKET sockets? AFAICS,
for those we never call unix_dgram_peer_wake_connect(), i.e. ->peer_wake.private
of any non-SOCK_DGRAM socker has to remain NULL. Which makes that call simply
spin_lock(&unix_sk(skpair)->peer_wait.lock);
spin_unlock(&unix_sk(skpair)->peer_wait.lock);
and that doesn't even serve as a barrier for anything else. Should that
have been
if (sk->sk_type == SOCK_STREAM || sk->sk_type == SOCK_SEQPACKET) {
unix_state_lock(skpair);
/* No more writes */
skpair->sk_shutdown = SHUTDOWN_MASK;
if (!skb_queue_empty(&sk->sk_receive_queue) || embrion)
skpair->sk_err = ECONNRESET;
unix_state_unlock(skpair);
skpair->sk_state_change(skpair);
sk_wake_async(skpair, SOCK_WAKE_WAITD, POLL_HUP);
} else {
unix_dgram_peer_wake_disconnect(sk, skpair);
}
or am I missing something subtle here?
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2019-02-24 6:28 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-02-24 6:28 [Q] why do we ever try to call unix_dgram_peer_wake_disconnect() for SOCK_STREAM? Al Viro
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).