linux-kernel - Re: [PATCH] gpio: Document the 'valid

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <46364d27-0316-4288-b559-209b4e41a533@gmail.com>
Date: Fri, 28 Feb 2025 12:00:06 +0200
From: Matti Vaittinen <mazziesaccount@...il.com>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
 Bartosz Golaszewski <brgl@...ev.pl>, linux-gpio@...r.kernel.org,
 linux-kernel@...r.kernel.org, Geert Uytterhoeven <geert+renesas@...der.be>
Subject: Re: [PATCH] gpio: Document the 'valid_mask' being internal

On 28/02/2025 11:42, Matti Vaittinen wrote:
> On 28/02/2025 11:28, Matti Vaittinen wrote:
>>
>> CC: Geert (because, I think he was asked about the Rcar GPIO check 
>> before).
>>
>> On 28/02/2025 10:23, Linus Walleij wrote:
>>> On Thu, Feb 27, 2025 at 9:24 AM Matti Vaittinen
>>> <mazziesaccount@...il.com> wrote:
> 
>>> The call graph should look like this:
>>>
>>> devm_gpiod_get_array()
>>>      gpiod_get_array()
>>>          gpiod_get_index(0...n)
>>>              gpiod_find_and_request()
>>>                  gpiod_request()
>>>                      gpiod_request_commit()
>>
>> Here in my setup the guard.gc->request == NULL. Thus the code never 
>> goes to the branch with the validation. And just before you ask me why 
>> the guard.gc->request is NULL - what do you call a blind bambi? :)
>>   - No idea.
> 
> Oh, I suppose the 'guard.gc' is just the chip structure. So, these 
> validity checks are only applied if the gc provides the request 
> callback? As far as I understand, the request callback is optional, and 
> thus the validity check for GPIOs may be omitted.
> 
>>
>>>                          gpiochip_line_is_valid()

Would something like this be appropriate? It seems to work "on my 
machine" :) Do you see any unwanted side-effects?

+++ b/drivers/gpio/gpiolib.c
@@ -2315,6 +2315,10 @@ static int gpiod_request_commit(struct gpio_desc 
*desc, const char *label)
         if (!guard.gc)
                 return -ENODEV;

+       offset = gpio_chip_hwgpio(desc);
+       if (!gpiochip_line_is_valid(guard.gc, offset))
+               return -EINVAL;
+
         if (test_and_set_bit(FLAG_REQUESTED, &desc->flags))
                 return -EBUSY;

@@ -2323,11 +2327,7 @@ static int gpiod_request_commit(struct gpio_desc 
*desc, const char *label)
          */

         if (guard.gc->request) {
-               offset = gpio_chip_hwgpio(desc);
-               if (gpiochip_line_is_valid(guard.gc, offset))
-                       ret = guard.gc->request(guard.gc, offset);
-               else
-                       ret = -EINVAL;
+               ret = guard.gc->request(guard.gc, offset);
                 if (ret)
                         goto out_clear_bit;
         }

I can craft a formal patch if this seems reasonable.

Yours,
	-- Matti