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
| ||
|
Message-ID: <574ca8dd-ee97-4c8b-a154-51faf83cabdf@leemhuis.info> Date: Thu, 14 Sep 2023 07:13:32 +0200 From: Thorsten Leemhuis <regressions@...mhuis.info> To: Luiz Augusto von Dentz <luiz.dentz@...il.com>, Linux regressions mailing list <regressions@...ts.linux.dev> Cc: patchwork-bot+bluetooth@...nel.org, linux-bluetooth@...r.kernel.org, netdev <netdev@...r.kernel.org>, Stefan Agner <stefan@...er.ch> Subject: Re: [PATCH] Bluetooth: hci_sync: Fix handling of HCI_QUIRK_STRICT_DUPLICATE_FILTER On 12.09.23 21:09, Luiz Augusto von Dentz wrote: > On Mon, Sep 11, 2023 at 6:40 AM Linux regression tracking (Thorsten > Leemhuis) <regressions@...mhuis.info> wrote: >> On 31.08.23 00:20, patchwork-bot+bluetooth@...nel.org wrote: >>> This patch was applied to bluetooth/bluetooth-next.git (master) >>> by Luiz Augusto von Dentz <luiz.von.dentz@...el.com>: >>> On Tue, 29 Aug 2023 13:59:36 -0700 you wrote: >>>> From: Luiz Augusto von Dentz <luiz.von.dentz@...el.com> >>>> >>>> When HCI_QUIRK_STRICT_DUPLICATE_FILTER is set LE scanning requires >>>> periodic restarts of the scanning procedure as the controller would >>>> consider device previously found as duplicated despite of RSSI changes, >>>> but in order to set the scan timeout properly set le_scan_restart needs >>>> to be synchronous so it shall not use hci_cmd_sync_queue which defers >>>> the command processing to cmd_sync_work. >>>> >>>> [...] >>> >>> Here is the summary with links: >>> - Bluetooth: hci_sync: Fix handling of HCI_QUIRK_STRICT_DUPLICATE_FILTER >>> https://git.kernel.org/bluetooth/bluetooth-next/c/52bf4fd43f75 >> >> That is (maybe among others?) a fix for a regression from 6.1, so why >> was this merged into a "for-next" branch instead of a branch that >> targets the current cycle? > > We were late for including it to 6.5, that said the regression was > introduced in 6.4, 6.4? From the fixes tag it sounded like it was 6.1. Whatever, doesn't make a difference, because: That answer doesn't answer the question afaics, as both 6.1 and 6.4 were released in the past year -- the fix thus should not wait till the next merge window, unless it's high risk or something. See this statement from Linus: https://lore.kernel.org/all/CAHk-=wis_qQy4oDNynNKi5b7Qhosmxtoj1jxo5wmB6SRUwQUBQ@mail.gmail.com/ > but I could probably have it marked for stable just > to make sure it would get backported to affected versions. That would be great, too! Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page.
Powered by blists - more mailing lists