Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp3252484pxk; Mon, 5 Oct 2020 05:20:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwCO5UcrD8+kiTRlh9/LHIuuPy23fCyCDM3szWURVe2raRpaopCc8NPrwO98xsU8lvrBmCe X-Received: by 2002:a17:906:82ce:: with SMTP id a14mr11712487ejy.84.1601900424109; Mon, 05 Oct 2020 05:20:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601900424; cv=none; d=google.com; s=arc-20160816; b=qB9BFpyAZVUUl3uYnof7g5nnPouSEGuU22NmetBKPLHV63yEK7v5lDke8kqJe2JGXT 4JuaHOdR7ERusimnCRo3LVThItaJE+L90H/iQiefm4CkLbA+KH9kve60jsPjmcKISVvf zswy4M3my3Np7G3iNAlkwqq96hcb5n0DxSf3z7dNMuSKGEZ6l8Jyvvh3DKpf94gBNj77 USjV1Dseb9XX0+SrEPhIVroL+xp/b3EkzSQ1NhiIUV8BDLSjoo0ffOW76xgweS2Eel5n zOFgO4EwmjyLAUqbkLfkYWiKNWgukClLgpKV7TMoDcPmpnGXnRDA07w6pS6+XhJyeFKl rdrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version; bh=ecuHWqEL4K3shcnH6cSnbj2eiJNO/33VJeL9cz/tBSM=; b=g4jnC0+10RZ07jq0khj8aKt+oTWF9KguvyenvT3VbqVcHVkiXKrmNqwurRLebSDbE+ n7iqd+PeFEmaIIKS4HOZfHeYjhDt/oHpRVK6ROWJoBtBC6mLjUIc8O9vyuCprtLKs+g/ j1v5daCtxH6rXJ4nYYrHEW03zZpaks1Vtyrlqnz5YUJM64kyqySdJDp80Ge8Uben3sqH 6zU5LXkx4+qAwXaFY7pxa/LouXXHlSu68ugLuqSDe5+cwUoZsh1D+2bfdbkxtGRz33f2 09h35WeSgXDR45CvElc0P+5hSoBHL9+U0acvod4b1FAdl4wRp6MeotOIjPjtdFvgnxBk Q6aQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bo17si6139295ejb.391.2020.10.05.05.19.44; Mon, 05 Oct 2020 05:20:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726410AbgJEMTf convert rfc822-to-8bit (ORCPT + 99 others); Mon, 5 Oct 2020 08:19:35 -0400 Received: from coyote.holtmann.net ([212.227.132.17]:49734 "EHLO mail.holtmann.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725939AbgJEMTf (ORCPT ); Mon, 5 Oct 2020 08:19:35 -0400 Received: from marcel-macpro.fritz.box (p4fefc7f4.dip0.t-ipconnect.de [79.239.199.244]) by mail.holtmann.org (Postfix) with ESMTPSA id 6F7CECED23; Mon, 5 Oct 2020 14:26:33 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: [PATCH] Revert "Bluetooth: Update resolving list when updating whitelist" From: Marcel Holtmann In-Reply-To: <20201005083624.GA2442@kroah.com> Date: Mon, 5 Oct 2020 14:19:32 +0200 Cc: Johan Hedberg , Sathish Narsimman , "David S. Miller" , Jakub Kicinski , linux-bluetooth , "open list:NETWORKING [GENERAL]" , linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8BIT Message-Id: <220D3B4E-D73E-43AD-8FF8-887D1A628235@holtmann.org> References: <20201003135449.GA2691@kroah.com> <20201003160713.GA1512229@kroah.com> <20201004105124.GA2429@kroah.com> <3F7BDD50-DEA3-4CB0-A9A0-69E7EE2923D5@holtmann.org> <20201005083624.GA2442@kroah.com> To: Greg Kroah-Hartman X-Mailer: Apple Mail (2.3608.120.23.2.1) Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org Hi Greg, >>>>>>> This reverts commit 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2 as it >>>>>>> breaks all bluetooth connections on my machine. >>>>>>> >>>>>>> Cc: Marcel Holtmann >>>>>>> Cc: Sathish Narsimman >>>>>>> Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when updating whitelist") >>>>>>> Signed-off-by: Greg Kroah-Hartman >>>>>>> --- >>>>>>> net/bluetooth/hci_request.c | 41 ++----------------------------------- >>>>>>> 1 file changed, 2 insertions(+), 39 deletions(-) >>>>>>> >>>>>>> This has been bugging me for since 5.9-rc1, when all bluetooth devices >>>>>>> stopped working on my desktop system. I finally got the time to do >>>>>>> bisection today, and it came down to this patch. Reverting it on top of >>>>>>> 5.9-rc7 restored bluetooth devices and now my input devices properly >>>>>>> work. >>>>>>> >>>>>>> As it's almost 5.9-final, any chance this can be merged now to fix the >>>>>>> issue? >>>>>> >>>>>> can you be specific what breaks since our guys and I also think the >>>>>> ChromeOS guys have been testing these series of patches heavily. >>>>> >>>>> My bluetooth trackball does not connect at all. With this reverted, it >>>>> all "just works". >>>>> >>>>> Same I think for a Bluetooth headset, can check that again if you really >>>>> need me to, but the trackball is reliable here. >>>>> >>>>>> When you run btmon does it indicate any errors? >>>>> >>>>> How do I run it and where are the errors displayed? >>>> >>>> you can do btmon -w trace.log and just let it run like tcdpump. >>> >>> Ok, attached. >>> >>> The device is not connecting, and then I open the gnome bluetooth dialog >>> and it scans for devices in the area, but does not connect to my >>> existing devices at all. >>> >>> Any ideas? >> >> the trace file is from -rc7 or from -rc7 with this patch reverted? >> >> I asked, because I see no hint that anything goes wrong. However I have a suspicion if you bisected it to this patch. >> >> diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c >> index e0269192f2e5..94c0daa9f28d 100644 >> --- a/net/bluetooth/hci_request.c >> +++ b/net/bluetooth/hci_request.c >> @@ -732,7 +732,7 @@ static int add_to_white_list(struct hci_request *req, >> return -1; >> >> /* White list can not be used with RPAs */ >> - if (!allow_rpa && !use_ll_privacy(hdev) && >> + if (!allow_rpa && >> hci_find_irk_by_addr(hdev, ¶ms->addr, params->addr_type)) { >> return -1; >> } >> @@ -812,7 +812,7 @@ static u8 update_white_list(struct hci_request *req) >> } >> >> /* White list can not be used with RPAs */ >> - if (!allow_rpa && !use_ll_privacy(hdev) && >> + if (!allow_rpa && >> hci_find_irk_by_addr(hdev, &b->bdaddr, b->bdaddr_type)) { >> return 0x00; >> } >> >> >> If you just do the above, does thing work for you again? > > Corrupted white-space issues aside, yes, it works! I just pasted it from a different terminal ;) > I am running 5.9-rc8 with just this change on it and my tracball works > just fine. > >> My suspicion is that the use_ll_privacy check is the wrong one here. It only checks if hardware feature is available, not if it is also enabled. > > How would one go about enabling such a hardware feature if they wanted > to? :) I need to understand what is going wrong for you. I have a suspicion, but first I need to understand what kind of device you have. I hope the trace file is enough. > Anyway, feel free to put: > > Tested-by: Greg Kroah-Hartman > > on the above patch and hopefully get it to Linus for 5.9-final. Sadly, it is a poor hot-needle fix. Regards Marcel