diff mbox series

Bluetooth: hci_sync: Fix handling of HCI_QUIRK_STRICT_DUPLICATE_FILTER

Message ID 20230829205936.766544-1-luiz.dentz@gmail.com (mailing list archive)
State Accepted
Commit 52bf4fd43f759ac4698f041fff2cb27691698265
Headers show
Series Bluetooth: hci_sync: Fix handling of HCI_QUIRK_STRICT_DUPLICATE_FILTER | expand

Checks

Context Check Description
tedd_an/pre-ci_am success Success
tedd_an/CheckPatch warning WARNING: Unknown link reference 'link:', use 'Link:' or 'Closes:' instead #90: link: https://lore.kernel.org/linux-bluetooth/578e6d7afd676129decafba846a933f5@agner.ch/#t total: 0 errors, 1 warnings, 0 checks, 30 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. /github/workspace/src/src/13369574.patch has style problems, please review. NOTE: Ignored message types: UNKNOWN_COMMIT_ID NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS.
tedd_an/GitLint fail WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search 12: B1 Line exceeds max length (90>80): "link: https://lore.kernel.org/linux-bluetooth/578e6d7afd676129decafba846a933f5@agner.ch/#t"
tedd_an/SubjectPrefix success Gitlint PASS
tedd_an/BuildKernel success BuildKernel PASS
tedd_an/CheckAllWarning success CheckAllWarning PASS
tedd_an/CheckSparse success CheckSparse PASS
tedd_an/CheckSmatch success CheckSparse PASS
tedd_an/BuildKernel32 success BuildKernel32 PASS
tedd_an/TestRunnerSetup success TestRunnerSetup PASS
tedd_an/TestRunner_l2cap-tester success TestRunner PASS
tedd_an/TestRunner_iso-tester success TestRunner PASS
tedd_an/TestRunner_bnep-tester success TestRunner PASS
tedd_an/TestRunner_mgmt-tester success TestRunner PASS
tedd_an/TestRunner_rfcomm-tester success TestRunner PASS
tedd_an/TestRunner_sco-tester success TestRunner PASS
tedd_an/TestRunner_ioctl-tester success TestRunner PASS
tedd_an/TestRunner_mesh-tester success TestRunner PASS
tedd_an/TestRunner_smp-tester success TestRunner PASS
tedd_an/TestRunner_userchan-tester success TestRunner PASS
tedd_an/IncrementalBuild success Incremental Build PASS

Commit Message

Luiz Augusto von Dentz Aug. 29, 2023, 8:59 p.m. UTC
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.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.

link: https://lore.kernel.org/linux-bluetooth/578e6d7afd676129decafba846a933f5@agner.ch/#t
Fixes: 27d54b778ad1 ("Bluetooth: Rework le_scan_restart for hci_sync")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
 net/bluetooth/hci_sync.c | 13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)

Comments

bluez.test.bot@gmail.com Aug. 29, 2023, 9:35 p.m. UTC | #1
This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=780332

---Test result---

Test Summary:
CheckPatch                    FAIL      0.96 seconds
GitLint                       FAIL      0.58 seconds
SubjectPrefix                 PASS      0.10 seconds
BuildKernel                   PASS      35.95 seconds
CheckAllWarning               PASS      35.32 seconds
CheckSparse                   PASS      39.77 seconds
CheckSmatch                   PASS      111.71 seconds
BuildKernel32                 PASS      30.60 seconds
TestRunnerSetup               PASS      472.66 seconds
TestRunner_l2cap-tester       PASS      26.59 seconds
TestRunner_iso-tester         PASS      47.41 seconds
TestRunner_bnep-tester        PASS      12.15 seconds
TestRunner_mgmt-tester        PASS      218.19 seconds
TestRunner_rfcomm-tester      PASS      15.49 seconds
TestRunner_sco-tester         PASS      18.88 seconds
TestRunner_ioctl-tester       PASS      17.38 seconds
TestRunner_mesh-tester        PASS      15.88 seconds
TestRunner_smp-tester         PASS      13.73 seconds
TestRunner_userchan-tester    PASS      10.71 seconds
IncrementalBuild              PASS      28.98 seconds

Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
Bluetooth: hci_sync: Fix handling of HCI_QUIRK_STRICT_DUPLICATE_FILTER
WARNING: Unknown link reference 'link:', use 'Link:' or 'Closes:' instead
#90: 
link: https://lore.kernel.org/linux-bluetooth/578e6d7afd676129decafba846a933f5@agner.ch/#t

total: 0 errors, 1 warnings, 0 checks, 30 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

/github/workspace/src/src/13369574.patch has style problems, please review.

NOTE: Ignored message types: UNKNOWN_COMMIT_ID

NOTE: If any of the errors are false positives, please report
      them to the maintainer, see CHECKPATCH in MAINTAINERS.


##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
Bluetooth: hci_sync: Fix handling of HCI_QUIRK_STRICT_DUPLICATE_FILTER

WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
12: B1 Line exceeds max length (90>80): "link: https://lore.kernel.org/linux-bluetooth/578e6d7afd676129decafba846a933f5@agner.ch/#t"


---
Regards,
Linux Bluetooth
patchwork-bot+bluetooth@kernel.org Aug. 30, 2023, 10:20 p.m. UTC | #2
Hello:

This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:

On Tue, 29 Aug 2023 13:59:36 -0700 you wrote:
> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.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

You are awesome, thank you!
Thorsten Leemhuis Sept. 11, 2023, 1:40 p.m. UTC | #3
On 31.08.23 00:20, patchwork-bot+bluetooth@kernel.org wrote:
> 
> This patch was applied to bluetooth/bluetooth-next.git (master)
> by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
> 
> On Tue, 29 Aug 2023 13:59:36 -0700 you wrote:
>> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.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?

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.

[1] see
https://lore.kernel.org/linux-bluetooth/b0b672069ee6a9e43fed1a07406c6dd3@agner.ch/
Luiz Augusto von Dentz Sept. 12, 2023, 7:09 p.m. UTC | #4
Hi,

On Mon, Sep 11, 2023 at 6:40 AM Linux regression tracking (Thorsten
Leemhuis) <regressions@leemhuis.info> wrote:
>
> On 31.08.23 00:20, patchwork-bot+bluetooth@kernel.org wrote:
> >
> > This patch was applied to bluetooth/bluetooth-next.git (master)
> > by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
> >
> > On Tue, 29 Aug 2023 13:59:36 -0700 you wrote:
> >> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.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, but I could probably have it marked for stable just
to make sure it would get backported to affected versions.

> 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.
>
> [1] see
> https://lore.kernel.org/linux-bluetooth/b0b672069ee6a9e43fed1a07406c6dd3@agner.ch/
Thorsten Leemhuis Sept. 14, 2023, 5:13 a.m. UTC | #5
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@leemhuis.info> wrote:
>> On 31.08.23 00:20, patchwork-bot+bluetooth@kernel.org wrote:
>>> This patch was applied to bluetooth/bluetooth-next.git (master)
>>> by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
>>> On Tue, 29 Aug 2023 13:59:36 -0700 you wrote:
>>>> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.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.
Luiz Augusto von Dentz Sept. 14, 2023, 5:51 p.m. UTC | #6
Hi Thorsten,

On Wed, Sep 13, 2023 at 10:13 PM Thorsten Leemhuis
<regressions@leemhuis.info> wrote:
>
> 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@leemhuis.info> wrote:
> >> On 31.08.23 00:20, patchwork-bot+bluetooth@kernel.org wrote:
> >>> This patch was applied to bluetooth/bluetooth-next.git (master)
> >>> by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
> >>> On Tue, 29 Aug 2023 13:59:36 -0700 you wrote:
> >>>> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.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:

It seems I had it confused with HCI_QUIRK_BROKEN_LE_CODED, so you are
right about this affecting from 6.1 onwards.

> 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/

Thanks for the feedback, I will try to push fixes to net more often.

> > 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!

Well now that it has already been merged via -next tree shall we still
attempt to mark it as stable? Perhaps we need to check if it was not
backported already based on the Fixes tag.

> 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.
Thorsten Leemhuis Sept. 14, 2023, 6:08 p.m. UTC | #7
On 14.09.23 19:51, Luiz Augusto von Dentz wrote:
> On Wed, Sep 13, 2023 at 10:13 PM Thorsten Leemhuis
> <regressions@leemhuis.info> wrote:
>> 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@leemhuis.info> wrote:
>>>> On 31.08.23 00:20, patchwork-bot+bluetooth@kernel.org wrote:
>>>>> This patch was applied to bluetooth/bluetooth-next.git (master)
>>>>> by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
>>>>> On Tue, 29 Aug 2023 13:59:36 -0700 you wrote:
>>>>>> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.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?
> [...]
>> 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/
> Thanks for the feedback, I will try to push fixes to net more often.

Great, many thx!

>>> 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!
> Well now that it has already been merged via -next tree shall we still
> attempt to mark it as stable? Perhaps we need to check if it was not
> backported already based on the Fixes tag.

Changes only get backported once they hit mainline, which hasn't
happened yet. And to get them into the net branch (and from there to
mainline) a new commit is needed anyway, so you might as well add the
stable tag to it. Side note: And don't worry that identical commit is
already in -next, git handles that well afaik (but if you rebase
bluetooth-next for other reasons anyway you might as well remove it).

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.
Thorsten Leemhuis Sept. 20, 2023, 2:02 p.m. UTC | #8
Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
for once, to make this easily accessible to everyone.

@Luiz Augusto von Dentz: did you make any progress to get this into net
to make sure this rather sooner then later heads to mainline? Doesn't
looks like it from here, but maybe I'm missing something.

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.

#regzbot poke


On 14.09.23 20:08, Thorsten Leemhuis wrote:
> On 14.09.23 19:51, Luiz Augusto von Dentz wrote:
>> On Wed, Sep 13, 2023 at 10:13 PM Thorsten Leemhuis
>> <regressions@leemhuis.info> wrote:
>>> 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@leemhuis.info> wrote:
>>>>> On 31.08.23 00:20, patchwork-bot+bluetooth@kernel.org wrote:
>>>>>> This patch was applied to bluetooth/bluetooth-next.git (master)
>>>>>> by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
>>>>>> On Tue, 29 Aug 2023 13:59:36 -0700 you wrote:
>>>>>>> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.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?
>> [...]
>>> 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/
>> Thanks for the feedback, I will try to push fixes to net more often.
> 
> Great, many thx!
> 
>>>> 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!
>> Well now that it has already been merged via -next tree shall we still
>> attempt to mark it as stable? Perhaps we need to check if it was not
>> backported already based on the Fixes tag.
> 
> Changes only get backported once they hit mainline, which hasn't
> happened yet. And to get them into the net branch (and from there to
> mainline) a new commit is needed anyway, so you might as well add the
> stable tag to it. Side note: And don't worry that identical commit is
> already in -next, git handles that well afaik (but if you rebase
> bluetooth-next for other reasons anyway you might as well remove it).
> 
> 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.
Luiz Augusto von Dentz Sept. 20, 2023, 6:27 p.m. UTC | #9
Hi Thorsten,

On Wed, Sep 20, 2023 at 7:02 AM Thorsten Leemhuis
<regressions@leemhuis.info> wrote:
>
> Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
> for once, to make this easily accessible to everyone.
>
> @Luiz Augusto von Dentz: did you make any progress to get this into net
> to make sure this rather sooner then later heads to mainline? Doesn't
> looks like it from here, but maybe I'm missing something.

Just sent the pull-request:

https://patchwork.kernel.org/project/bluetooth/patch/20230920181344.571274-1-luiz.dentz@gmail.com/

> 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.
>
> #regzbot poke
>
>
> On 14.09.23 20:08, Thorsten Leemhuis wrote:
> > On 14.09.23 19:51, Luiz Augusto von Dentz wrote:
> >> On Wed, Sep 13, 2023 at 10:13 PM Thorsten Leemhuis
> >> <regressions@leemhuis.info> wrote:
> >>> 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@leemhuis.info> wrote:
> >>>>> On 31.08.23 00:20, patchwork-bot+bluetooth@kernel.org wrote:
> >>>>>> This patch was applied to bluetooth/bluetooth-next.git (master)
> >>>>>> by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
> >>>>>> On Tue, 29 Aug 2023 13:59:36 -0700 you wrote:
> >>>>>>> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.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?
> >> [...]
> >>> 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/
> >> Thanks for the feedback, I will try to push fixes to net more often.
> >
> > Great, many thx!
> >
> >>>> 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!
> >> Well now that it has already been merged via -next tree shall we still
> >> attempt to mark it as stable? Perhaps we need to check if it was not
> >> backported already based on the Fixes tag.
> >
> > Changes only get backported once they hit mainline, which hasn't
> > happened yet. And to get them into the net branch (and from there to
> > mainline) a new commit is needed anyway, so you might as well add the
> > stable tag to it. Side note: And don't worry that identical commit is
> > already in -next, git handles that well afaik (but if you rebase
> > bluetooth-next for other reasons anyway you might as well remove it).
> >
> > 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.
diff mbox series

Patch

diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
index 9b93653c6197..fd7c5d902856 100644
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@ -413,11 +413,6 @@  static int hci_le_scan_restart_sync(struct hci_dev *hdev)
 					   LE_SCAN_FILTER_DUP_ENABLE);
 }
 
-static int le_scan_restart_sync(struct hci_dev *hdev, void *data)
-{
-	return hci_le_scan_restart_sync(hdev);
-}
-
 static void le_scan_restart(struct work_struct *work)
 {
 	struct hci_dev *hdev = container_of(work, struct hci_dev,
@@ -427,15 +422,15 @@  static void le_scan_restart(struct work_struct *work)
 
 	bt_dev_dbg(hdev, "");
 
-	hci_dev_lock(hdev);
-
-	status = hci_cmd_sync_queue(hdev, le_scan_restart_sync, NULL, NULL);
+	status = hci_le_scan_restart_sync(hdev);
 	if (status) {
 		bt_dev_err(hdev, "failed to restart LE scan: status %d",
 			   status);
-		goto unlock;
+		return;
 	}
 
+	hci_dev_lock(hdev);
+
 	if (!test_bit(HCI_QUIRK_STRICT_DUPLICATE_FILTER, &hdev->quirks) ||
 	    !hdev->discovery.scan_start)
 		goto unlock;