linux-kernel - Re: [PATCH 2/2] Bluetooth: btbcm: automate node cleanup in btbcm_get_board

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: <6db7798c-6bd0-459a-bd73-ae8115736872@kernel.org>
Date: Thu, 31 Oct 2024 12:44:15 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Javier Carrasco <javier.carrasco.cruz@...il.com>,
 Marcel Holtmann <marcel@...tmann.org>,
 Luiz Augusto von Dentz <luiz.dentz@...il.com>,
 Linus Walleij <linus.walleij@...aro.org>
Cc: linux-bluetooth@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] Bluetooth: btbcm: automate node cleanup in
 btbcm_get_board_name()

On 31/10/2024 12:29, Javier Carrasco wrote:
> On 31/10/2024 12:14, Krzysztof Kozlowski wrote:
>> On 31/10/2024 12:10, Javier Carrasco wrote:
>>> On 31/10/2024 12:08, Krzysztof Kozlowski wrote:
>>>> On 30/10/2024 16:46, Javier Carrasco wrote:
>>>>> Switch to a more robust approach by automating the node release when it
>>>>> goes out of scope, removing the need for explicit calls to
>>>>> of_node_put().
>>>>>
>>>>> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@...il.com>
>>>>> ---
>>>>>  drivers/bluetooth/btbcm.c | 8 ++------
>>>>>  1 file changed, 2 insertions(+), 6 deletions(-)
>>>>>
>>>>> diff --git a/drivers/bluetooth/btbcm.c b/drivers/bluetooth/btbcm.c
>>>>> index 400c2663d6b0..a1153ada74d2 100644
>>>>> --- a/drivers/bluetooth/btbcm.c
>>>>> +++ b/drivers/bluetooth/btbcm.c
>>>>> @@ -541,23 +541,19 @@ static const struct bcm_subver_table bcm_usb_subver_table[] = {
>>>>>  static const char *btbcm_get_board_name(struct device *dev)
>>>>>  {
>>>>>  #ifdef CONFIG_OF
>>>>> -	struct device_node *root;
>>>>> +	struct device_node *root __free(device_node) = of_find_node_by_path("/");
>>>>>  	char *board_type;
>>>>>  	const char *tmp;
>>>>>  
>>>>> -	root = of_find_node_by_path("/");
>>>>>  	if (!root)
>>>>>  		return NULL;
>>>>>  
>>>>> -	if (of_property_read_string_index(root, "compatible", 0, &tmp)) {
>>>>> -		of_node_put(root);
>>>>
>>>> You just added this. Don't add code which is immediately removed. It's a
>>>> noop or wrong code.
>>>>
>>>>
>>>>
>>>> Best regards,
>>>> Krzysztof
>>>>
>>>
>>> Exactly, I added that code to fix the issue in stable kernels that don't
>>
>> Then send backport for stable.
>>
>>> support the __free() macro, and then I removed it to use a safer
>>> approach from now on.
>>
>> This is not correct approach. We work here on mainline and in mainline
>> this is one logical change: fixing issue. Whether you fix issue with
>> of_node_put or cleanup or by removing of_find_node_by_path() call, it
>> does not matter. All of these are fixing the same, one issue.
>>
> 
> I fixed an issue as one logical change, and tagged it for stable kernels
> so it can be automatically applied. Then a second logical change
> switched to the new approach, removing the old solution. If that
> happened with a few weeks in between, it would be ok, right? And no one
> would have to choose the fixes to backport for a given stable kernel.

I did not address this.

That's the same with every work in the kernel. You create a driver and
you send it. It's one commit, for regular cases of drivers (not too
big). You do not send two commits:
1. Add basic driver, built-in because supporting module is difficult.
2. Add some feature, like converting built-in to module.

Now, because we all release early, release often you could release first
built-in driver and then come later (*later*) and develop second patch
improving it, e.g. converting to module.

It's exactly the same here. You fix issue. If you want to split your
contributions and release fixes early, sure, go on. It's different than
you know and you have the code ready which makes the first fix totally
obsolete.

Best regards,
Krzysztof