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>
 <CAJQfnxG_AnWArBg8_Pg3coAeFbRuG08KkXh1G==CuXWCvJpf5Q@mail.gmail.com>
In-Reply-To: <CAJQfnxG_AnWArBg8_Pg3coAeFbRuG08KkXh1G==CuXWCvJpf5Q@mail.gmail.com>
From:   Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date:   Mon, 13 Apr 2020 09:10:44 -0700
Message-ID: <CABBYNZLYzsKNknN_A4GaRevh=32=dGrPDPW-ksSGd7+PrGXS6Q@mail.gmail.com>
Subject: Re: [Bluez PATCH v1] input: disconnect intr channel before ctrl channel
To:     Archie Pusaka <apusaka@google.com>
Cc:     Marcel Holtmann <marcel@holtmann.org>,
        linux-bluetooth <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Archie,

On Mon, Apr 13, 2020 at 6:48 AM Archie Pusaka <apusaka@google.com> wrote:
>
> 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

That was what I meant on my reply, that way we can detect if the has
been shutdown on both directions or not, so in case of SHUT_WR it
shall on indicate POLL_HUP if the userspace is polling with POLL_OUT,
thus POLL_IN would still wait for the disconnect to complete, I guess
this is worth the shot since this does not introduce any new APIs, but
we might want to introduce a test to l2cap-tester to cover this
functionality.

> 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


-- 
Luiz Augusto von Dentz