linux-kernel - Re: [PATCH 01/13] acpi: utils: Cleanup acpi_dev_match

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 6 Jun 2019 10:21:38 +0100
From:   Suzuki K Poulose <suzuki.poulose@....com>
To:     rafael@...nel.org
Cc:     linux-kernel@...r.kernel.org, gregkh@...uxfoundation.org,
        rjw@...ysocki.net, lenb@...nel.org, linux-acpi@...r.kernel.org
Subject: Re: [PATCH 01/13] acpi: utils: Cleanup acpi_dev_match_cb

Hi Rafael,

On 06/06/2019 10:14, Rafael J. Wysocki wrote:
> On Wed, Jun 5, 2019 at 5:14 PM Suzuki K Poulose <suzuki.poulose@....com> wrote:
>>
>> acpi_dev_match_cb match function modifies the "data" argument
>> to pass on a result which could be easily deduced from the result
>> of the bus_find_device() call at the caller site. Clean this
>> up in preparation to convert the "match" argument for bus_find_device
>> to accept a "const" data pointer, similar to class_find_device. This
>> would allow consolidating the match routines for these two APIs.
> 
> This changelog can be improved IMO.

I agree. Will update it.

> 
> In fact, the final goal here is to pass (const void *) as the second
> argument to acpi_dev_match_cb() (which you could do right away in this
> patch if I'm not mistaken) which is because you want to modify the
> prototype of bus_find_device().
> 
> So why don't you write something like this in the changelog:
> 
> "The prototype of bus_find_device() will be unified with that of
> class_find_device() subsequently, but for this purpose the callback
> functions passed to it need to take (const void *) as the second
> argument.  Consequently, they cannot modify the memory pointed to by
> that argument which currently is not the case for acpi_dev_match_cb().
> However, acpi_dev_match_cb() really need not modify the "match" object
> passed to it, because acpi_dev_get_first_match_dev() which uses it via
> bus_find_device() can easily convert the result of bus_find_device()
> into the pointer to return.

Sure.

> For this reason, update acpi_dev_match_cb() to avoid the redundant
> memory updates and change the type of its second argument to (const
> void *)."

We can't do that quite yet, until we unify the prototype of the
bus_find_device().

>>
>> Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>
>> Cc: Len Brown <lenb@...nel.org>
>> Cc: linux-acpi@...r.kernel.org
>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@....com>
>> ---
>>   drivers/acpi/utils.c | 7 +------
>>   1 file changed, 1 insertion(+), 6 deletions(-)
>>
>> diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c
>> index 7def63a..1391b63 100644
>> --- a/drivers/acpi/utils.c
>> +++ b/drivers/acpi/utils.c
>> @@ -725,8 +725,6 @@ bool acpi_dev_found(const char *hid)
>>   EXPORT_SYMBOL(acpi_dev_found);
>>
>>   struct acpi_dev_match_info {
>> -       const char *dev_name;
>> -       struct acpi_device *adev;
>>          struct acpi_device_id hid[2];
>>          const char *uid;
>>          s64 hrv;
>> @@ -746,9 +744,6 @@ static int acpi_dev_match_cb(struct device *dev, void *data)
> 
> And why not to change the type of the second arg to "const void *data" here?

Because, that would conflict with what bus_find_device() expects now. We make
the change only later. Since this change was a bit more intrusive than simply
changing the type of the parameter, I kept it as a preparatory patch.

Thanks for the review !

Suzuki