Hi Marcel, Luiz, I found out that shutdown second parameter is passed as the "how" parameter in l2cap_sock_shutdown() [1]. Currently the value of the parameter is unused, but I think we can assign it to sk->sk_shutdown. Therefore, we can differentiate whether we are interested to wait for the disconnection reply or not, by supplying SHUT_RDWR and SHUT_WR, respectively. Do you think this is a sound idea? [1] https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/tree/net/bluetooth/l2cap_sock.c#n1267 Thanks, Archie On Wed, 18 Mar 2020 at 20:41, Archie Pusaka <apusaka@xxxxxxxxxx> wrote: > > > > I see, we shutdown the socket immediately since the socket API itself > > > don't seem to have a concept of disconnect syscall not sure if other > > > values could be passed to shutdown second parameter to indicate we > > > want to actually wait it to be disconnected. > > I don't think the second parameter matters, I tried every possible > valid values and intr_watch_cb is still called without waiting for the > response. > > > > > in a blocking synchronous system call world we have SO_LINGER for that. In the world of asynchronous IO handling (what we do), we need to check what is the right way of handling this. > > > > I spot this piece of code [1] which utilizes getsockopt to query > socket connection information from the kernel space to the user space. > We can use a similar method to query whether (sk->sk_state == > BT_CLOSED), which is only true when we get the response. > What do you think? > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/tree/net/bluetooth/l2cap_sock.c#n476
