Re: Bluetooth kernel BUG with Intel AX211 (regression in 6.1.83)

[Greg KH <gregkh@linuxfoundation.org>]

On Tue, Nov 12, 2024 at 12:54:46PM +0100, Thorsten Leemhuis wrote:
> On 07.11.24 05:38, Greg KH wrote:
> > On Wed, Nov 06, 2024 at 10:02:40AM -0500, Luiz Augusto von Dentz wrote:
> >> On Wed, Nov 6, 2024 at 2:40 AM Salvatore Bonaccorso <carnil@debian.org> wrote:
> >>> On Wed, Nov 06, 2024 at 08:26:05AM +0100, Greg KH wrote:
> >>>> On Tue, Nov 05, 2024 at 08:23:59PM +0100, Salvatore Bonaccorso wrote:
> >>>>> On Tue, Nov 05, 2024 at 12:53:50PM -0500, Luiz Augusto von Dentz wrote:
> >>>>>> On Tue, Nov 5, 2024 at 12:29 PM Thorsten Leemhuis
> >>>>>> <regressions@leemhuis.info> wrote:
> >>>>>>> On 31.10.24 07:33, Salvatore Bonaccorso wrote:
> >>>>>>>> On Tue, Jun 18, 2024 at 12:30:18PM +0200, Thorsten Leemhuis wrote:
> >>>>>>>>> On 12.06.24 14:04, Greg KH wrote:
> >>>>>>>>>> On Thu, Jun 06, 2024 at 12:18:18PM +0200, Thorsten Leemhuis wrote:
> >>>>>>>>>>> On 03.06.24 22:03, Mike wrote:
> >>>>>>>>>>>> On 29.05.24 11:06, Thorsten Leemhuis wrote:
> >>>>>>>>>>>> [...]
> >>>>>>>>>>>> I understand that 6.9-rc5[1] worked fine, but I guess it will take some
> >>>>>>>>>>>> time to be
> >>>>>>>>>>>> included in Debian stable, so having a patch for 6.1.x will be much
> >>>>>>>>>>>> appreciated.
> >>>>>>>>>>>> I do not have the time to follow the vanilla (latest) release as is
> >>>>>>>>>>>> likely the case for
> >>>>>>>>>>>> many other Linux users.
> >>>>>>>>>>>>
> >>>>>>>>>>> Still no reaction from the bluetooth developers. Guess they are busy
> >>>>>>>>>>> and/or do not care about 6.1.y. In that case:
> >>>>>>>>>>>
> >>>>>>>>>>> @Greg: do you might have an idea how the 6.1.y commit a13f316e90fdb1
> >>>>>>>>>>> ("Bluetooth: hci_conn: Consolidate code for aborting connections") might
> >>>>>>>>>>> cause this or if it's missing some per-requisite? If not I wonder if
> >>>>>>>>>>> reverting that patch from 6.1.y might be the best move to resolve this
> >>>>>>>>>>> regression. Mike earlier in
> >>>>>>>>>>> https://lore.kernel.org/all/c947e600-e126-43ea-9530-0389206bef5e@gmail.com/
> >>>>>>>>>>> confirmed that this fixed the problem in tests. Jeremy (who started the
> >>>>>>>>>>> thread and afaics has the same problem) did not reply.
> >>>>>>>>>>
> >>>>>>>>>> How was this reverted?  I get a bunch of conflicts as this commit was
> >>>>>>>>>> added as a dependency of a patch later in the series.
> >>>>>>>>>>
> >>>>>>>>>> So if this wants to be reverted from 6.1.y, can someone send me the
> >>>>>>>>>> revert that has been tested to work?
> >>>>>>>>>
> >>>>>>>>> Mike, can you help out here, as you apparently managed a revert earlier?
> >>>>>>>>> Without you or someone else submitting a revert I fear this won't be
> >>>>>>>>> resolved...
> >>>>>>>>
> >>>>>>>> Trying to reboostrap this, as people running 6.1.112 based kernel
> >>>>>>>> seems still hitting the issue, but have not asked yet if it happens as
> >>>>>>>> well for 6.114.
> >>>>>>>>
> >>>>>>>> https://bugs.debian.org/1086447
> >>>>>>>>
> >>>>>>>> Mike, since I guess you are still as well affected as well, does the
> >>>>>>>> issue trigger on 6.1.114 for you and does reverting changes from
> >>>>>>>> a13f316e90fdb1 still fix the issue? Can you send your
> >>>>>>>> backport/changes?
> >>>>>>>
> >>>>>>> Hmmm, no reply. Is there maybe someone in that bug that could create and
> >>>>>>> test a new revert to finally get this resolved upstream? Seem we
> >>>>>>> otherwise are kinda stuck here.
> >>>>>>
> >>>>>> Looks like we didn't tag things like 5af1f84ed13a ("Bluetooth:
> >>>>>> hci_sync: Fix UAF on hci_abort_conn_sync") and a239110ee8e0
> >>>>>> ("Bluetooth: hci_sync: always check if connection is alive before
> >>>>>> deleting") that are actually fixes to a13f316e90fdb1.
> >>>>>
> >>>>> Ah good I see :). None of those were yet applied to the 6.1.y series
> >>>>> were the issue is still presend. Would you be up to provide the needed
> >>>>> changes to the stable team?  That would be very much appreciated for
> >>>>> those affected running the 6.1.y series.
> >>>>
> >>>> We would need backports for these as they do not apply cleanly :(
> >>>
> >>> Looks our mails overlapped, yes came to the same conclusion as I tried
> >>> to apply them on top of 6.1.y. I hope Luiz can help here.
> >>>
> >>> We have defintively users in Debian affected by this, and two
> >>> confirmed that using a newer kernel which contains naturally those
> >>> fixes do not expose the problem. If we have backports I might be able
> >>> to convice those affected users to test our 6.1.115-1 + patches to
> >>> verify the issue is gone.
> >>
> >> Then perhaps it is easier to just revert that change?
> > 
> > Please send a revert then.
> 
> We afaics are kinda stuck here .
> 
> Seems Mike (who apparently had a local revert that worked) does not care
> anymore.
> 
> It looks like Luiz does not care about 6.1.y either, which is fine, as
> participation in stable is optional.
> 
> And looks like nobody else cares enough and has the skills to
> prepare and submit a revert.
> 
> In the end the one that asked for the changes to be included in the
> 6.1.y series thus submit one. Not sure who that is, though, a very quick
> search on Lore gave no answer. :-/
> 
> There is also still the question "might a revert now cause another
> regression for users of the 6.1.y series, as the change might improved
> things for other users".
> 
> :-(

I care as this affects Debian, which is the largest user of Linux
outside of Android.  I'll try to do a local version of the revert to
unstick this...

thanks for reminding me.

greg k-h