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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 29 Jul 2021 14:27:12 -0700
From:   Cong Wang <>
To:     John Fastabend <>
Cc:     Jiang Wang <>,
        Linux Kernel Network Developers <>,
        "Cong Wang ." <>,
        Xiongchun Duan <>,,,
        "David S. Miller" <>,
        Jakub Kicinski <>,
        Daniel Borkmann <>,
        Jakub Sitnicki <>,
        Lorenz Bauer <>,
        Alexei Starovoitov <>,
        Andrii Nakryiko <>,
        Martin KaFai Lau <>,
        Song Liu <>, Yonghong Song <>,
        KP Singh <>, Shuah Khan <>,
        Johan Almbladh <>,
        LKML <>, bpf <>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
Subject: Re: [PATCH bpf-next v1 2/5] af_unix: add unix_stream_proto for sockmap

On Wed, Jul 28, 2021 at 11:44 AM John Fastabend
<> wrote:
> Cong Wang wrote:
> > On Tue, Jul 27, 2021 at 9:37 AM John Fastabend <> wrote:
> > > Do we really need an unhash hook for unix_stream? I'm doing some testing
> > > now to pull it out of TCP side as well. It seems to be an artifact of old
> > > code that is no longer necessary. On TCP side at least just using close()
> > > looks to be enough now.
> >
> > How do you handle the disconnection from remote without ->unhash()?
> Would close() not work for stream/dgram sockets?

close() is called when the local closes the sockets, but when the remote
closes or disconnects it, unhash() is called. This is why TCP calls unhash()
to remove the socket from established socket hash table. unhash() itself
might not make much sense for AF_UNIX as it probably does not need a
hash table to track established ones, however, the idea is the same, that
is, we have to handle remote disconnections here.


Powered by blists - more mailing lists