On Tue, Nov 12, 2024 at 01:04:03PM +0100, Greg KH wrote:
> 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@xxxxxxxxxx> 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@xxxxxxxxxxxxx> 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@xxxxxxxxx/
> > >>>>>>>>>>> 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...
Ok, I have a series of reverts that seems to build properly for 6.1.y
that I'll queue up after this round of stable releases goes out
tomorrrow to hopefully resolve this.
thanks,
greg k-h
