[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <57af5c65ee5510ce03c451456679be7654a4047b.camel@redhat.com>
Date: Mon, 16 Oct 2023 08:38:05 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Luiz Augusto von Dentz <luiz.dentz@...il.com>, Jakub Kicinski
<kuba@...nel.org>
Cc: davem@...emloft.net, linux-bluetooth@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: pull-request: bluetooth 2023-10-11
On Fri, 2023-10-13 at 20:12 -0700, Luiz Augusto von Dentz wrote:
> Hi Jakub,
>
> On Fri, Oct 13, 2023 at 5:54 PM Jakub Kicinski <kuba@...nel.org> wrote:
> >
> > On Wed, 11 Oct 2023 12:15:24 -0700 Luiz Augusto von Dentz wrote:
> > > - Fix race when opening vhci device
> > > - Avoid memcmp() out of bounds warning
> > > - Correctly bounds check and pad HCI_MON_NEW_INDEX name
> > > - Fix using memcmp when comparing keys
> > > - Ignore error return for hci_devcd_register() in btrtl
> > > - Always check if connection is alive before deleting
> > > - Fix a refcnt underflow problem for hci_conn
> >
> > Commit: fc11ae648f03 ("Bluetooth: hci_sock: Correctly bounds check and pad HCI_MON_NEW_INDEX name")
> > Fixes tag: Fixes: 78480de55a96 ("Bluetooth: hci_sock: fix slab oob read in create_monitor_event")
> > Has these problem(s):
> > - Target SHA1 does not exist
> >
> > Commit: 6f0ff718ed67 ("Bluetooth: avoid memcmp() out of bounds warning")
> > Fixes tag: Fixes: d70e44fef8621 ("Bluetooth: Reject connection with the device which has same BD_ADDR")
> > Has these problem(s):
> > - Target SHA1 does not exist
> >
> > Commit: b03f32b195df ("Bluetooth: hci_event: Fix coding style")
> > Fixes tag: Fixes: d70e44fef862 ("Bluetooth: Reject connection with the device which has same BD_ADDR")
> > Has these problem(s):
> > - Target SHA1 does not exist
> >
> > Commit: a9500f272b3b ("Bluetooth: hci_event: Fix using memcmp when comparing keys")
> > Fixes tag: Fixes: fe7a9da4fa54 ("Bluetooth: hci_event: Ignore NULL link key")
> > Has these problem(s):
> > - Target SHA1 does not exist
> >
> > :(
>
> Not sure what I'm doing wrong, because verify_fixes.sh doesn't
> actually warn these for me, or perhaps it needs to be used in a clean
> tree/new clone since it may match commit ids of different
> branchs/remotes?
Indeed verify_fixes will match any commit in your tree. I personally
stumbled upon similar issues while doing backports - when references to
different trees converged in my repo.
One things that did help me is using a specific, clean, clone with a
single remote for all the netdev patches.
Cheers,
Paolo
> Anyway, I'm preparing a new pull-request.
Powered by blists - more mailing lists