lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20190224062803.GG2217@ZenIV.linux.org.uk> Date: Sun, 24 Feb 2019 06:28:12 +0000 From: Al Viro <viro@...iv.linux.org.uk> To: netdev@...r.kernel.org Cc: Rainer Weikusat <rweikusat@...ileactivedefense.com> Subject: [Q] why do we ever try to call unix_dgram_peer_wake_disconnect() for SOCK_STREAM? 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?
Powered by blists - more mailing lists