Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Subject: Re: [PATCH 4/7] Bluetooth: LL_PRIVACY re-load resolving list
From:   Marcel Holtmann <marcel@holtmann.org>
In-Reply-To: <20200312100754.3445-5-sathish.narasimman@intel.com>
Date:   Wed, 18 Mar 2020 12:06:48 +0100
Cc:     linux-bluetooth <linux-bluetooth@vger.kernel.org>,
        chethan.tumkur.narayan@intel.com,
        Sathish Narsimman <sathish.narasimman@intel.com>,
        Joy Shermin <shermin.joy@intel.com>
Content-Transfer-Encoding: 8BIT
Message-Id: <7F7F5693-AF9F-423C-9439-FD394CC4A8B1@holtmann.org>
References: <20200312100754.3445-1-sathish.narasimman@intel.com>
 <20200312100754.3445-5-sathish.narasimman@intel.com>
To:     Sathish Narsimman <nsathish41@gmail.com>
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Sathish,

> The patch is used to load the entries in the local IRK to the
> Bluetooth LE controller resolving list.
> 
> Signed-off-by: Sathish Narsimman <sathish.narasimman@intel.com>
> Signed-off-by: Joy Shermin <shermin.joy@intel.com>
> ---
> include/net/bluetooth/hci_core.h |  1 +
> net/bluetooth/hci_request.c      | 29 +++++++++++++++++++++++++++++
> 2 files changed, 30 insertions(+)
> 
> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> index 43d31a9339a6..46d2d3e10c97 100644
> --- a/include/net/bluetooth/hci_core.h
> +++ b/include/net/bluetooth/hci_core.h
> @@ -1659,6 +1659,7 @@ void hci_copy_identity_address(struct hci_dev *hdev, bdaddr_t *bdaddr,
> 			       u8 *bdaddr_type);
> int hci_req_update_resolving_list(struct hci_dev *hdev,  u8 addr_type,
> 				  bdaddr_t *bdaddr, u8 irk[16]);
> +void hci_load_resolving_list(struct hci_dev *hdev);
> void hci_req_update_resolving_list_local_irk(struct hci_dev *hdev);
> 
> void hci_req_del_from_resolving_list(struct hci_dev *hdev, u8 addr_type,
> diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c
> index 9ffb62178d24..e17db3103a3d 100644
> --- a/net/bluetooth/hci_request.c
> +++ b/net/bluetooth/hci_request.c
> @@ -1015,6 +1015,35 @@ void hci_req_update_resolving_list_local_irk(struct hci_dev *hdev)
> 	hci_req_run(&req, NULL);
> }
> 
> +void hci_load_resolving_list (struct hci_dev *hdev)
> +{
> +	struct smp_irk *irk;
> +	u8 num = 0;
> +
> +	/* Nothing to be done if LL privacy is not supported */
> +	if ( !(hdev->le_features[0] & HCI_LE_LL_PRIVACY) )
> +		return;
> +
> +	if ( !hci_dev_test_flag(hdev, HCI_LL_RPA_RESOLUTION) &&
> +	    ( hci_dev_test_flag(hdev, HCI_LE_ADV) ||
> +	      hci_dev_test_flag(hdev, HCI_LE_SCAN) ||
> +	      hci_lookup_le_connect(hdev) ) )
> +		return;
> +
> +	/* Load the first le_resolving_list_size entries from IRK
> +	 * list in to resolving list.
> +	 */
> +	rcu_read_lock();
> +	list_for_each_entry_rcu(irk, &hdev->identity_resolving_keys, list) {
> +		if (num++ >= hdev->le_resolv_list_size)
> +			return;
> +
> +		hci_req_update_resolving_list(hdev, irk->addr_type, &irk->bdaddr, irk->val);
> +	}

I comparison to the le_whitelist, the le_resolv_list_size does not have to match the actual available memory of the controller. It is just some guesstimate. I think we have to design this in a way that we add the IRK anyway and handle the error case gracefully.

I am also confused why we are not actually checking here if an entry is already present and just loading the whole list. I have seen code being duplicated in at least 3 places now.

Regards

Marcel