Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200316123914.Bluez.v1.1.I2c83372de789a015c1ee506690bb795ee0b0b0d9@changeid>
 <CABBYNZL1D44M4z2c+4zbjLgZ=PMHsTwy1VpYZpsJbpFJ9POZug@mail.gmail.com>
 <CAJQfnxEFM81DSvZb+ULG7+nwQuy-GWj26GWn4OP+Bp--24N1CQ@mail.gmail.com>
 <CABBYNZ+=wMNuvjJ5VK2zpd6euqeEZ8JXbd67RmPgxDfdCgce9w@mail.gmail.com>
 <14E46BF4-0688-4A0B-AE84-46C4426C5E9A@holtmann.org> <CAJQfnxELMMDa6nbxRUrW46VjEBj6Txfeym62PKi+R3iXHKU0CQ@mail.gmail.com>
In-Reply-To: <CAJQfnxELMMDa6nbxRUrW46VjEBj6Txfeym62PKi+R3iXHKU0CQ@mail.gmail.com>
From:   Archie Pusaka <apusaka@google.com>
Date:   Mon, 13 Apr 2020 21:47:59 +0800
Message-ID: <CAJQfnxG_AnWArBg8_Pg3coAeFbRuG08KkXh1G==CuXWCvJpf5Q@mail.gmail.com>
Subject: Re: [Bluez PATCH v1] input: disconnect intr channel before ctrl channel
To:     Marcel Holtmann <marcel@holtmann.org>
Cc:     Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
        linux-bluetooth <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

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@google.com> 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