netdev - Re: pull request: bluetooth 2024-10-16

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9e03dba5-1aed-46b3-8aee-c5bde6d4eaec@leemhuis.info>
Date: Mon, 21 Oct 2024 10:22:41 +0200
From: Thorsten Leemhuis <regressions@...mhuis.info>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
 Luiz Augusto von Dentz <luiz.dentz@...il.com>
Cc: davem@...emloft.net, kuba@...nel.org, linux-bluetooth@...r.kernel.org,
 netdev@...r.kernel.org,
 Linux kernel regressions list <regressions@...ts.linux.dev>,
 Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>
Subject: Re: pull request: bluetooth 2024-10-16

On 20.10.24 23:25, Linus Torvalds wrote:
> On Fri, 18 Oct 2024 at 09:45, Luiz Augusto von Dentz
> <luiz.dentz@...il.com> wrote:
>>
>> I really would like to send the PR sooner but being on the path of
>> hurricane milton made things more complicated, anyway I think the most
>> important ones are the regression fixes:
>>
>>       Bluetooth: btusb: Fix not being able to reconnect after suspend
>>       Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001

BTW, Luiz, thanks for backing up my request, especially given the Milton
aspect!

> I cherry-picked just those, but then I ended up looking at the rest
> just to see if duplicating the commits was worth it.
> 
> And that just made me go "nope", and I undid my cherry-picks and
> instead just pulled the whole thing.

Thx!

> IOW: I've pulled the bluetooth fixes branch directly, but sincerely
> hope this won't become a pattern.

Just to clarify: I assume it's the "taking things directly and thus
bypassing -net" that is the problem here? So if the -net maintainers
would have pulled this on say Friday[1] and sent a second PR that week
it in a case like this would have been totally fine?

Ciao, Thorsten