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".
:-(
Ciao, Thorsten