[PATCH] gpiolib: Fix locking on gpio debugfs files

[PATCH] gpiolib: Fix locking on gpio debugfs files

[Grant Likely]

The debugfs files really need to hold the gpiolib spinlock before
accessing the list. Otherwise chip addition/removal will cause an oops.

Cc: Alexandre Courbot <acourbot@nvidia.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
 drivers/gpio/gpiolib.c |   12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 8ccf68b..807c9d3 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1884,29 +1884,35 @@ static void gpiolib_dbg_show(struct seq_file *s, struct gpio_chip *chip)
 
 static void *gpiolib_seq_start(struct seq_file *s, loff_t *pos)
 {
+	unsigned long flags;
 	struct gpio_chip *chip = NULL;
 	loff_t index = *pos;
 
-	/* REVISIT this isn't locked against gpio_chip removal ... */
-
 	s->private = "";
 
+	spin_lock_irqsave(&gpio_lock, flags);
 	list_for_each_entry(chip, &gpio_chips, list)
-		if (index-- == 0)
+		if (index-- == 0) {
+			spin_unlock_irqrestore(&gpio_lock, flags);
 			return chip;
+		}
+	spin_unlock_irqrestore(&gpio_lock, flags);
 
 	return NULL;
 }
 
 static void *gpiolib_seq_next(struct seq_file *s, void *v, loff_t *pos)
 {
+	unsigned long flags;
 	struct gpio_chip *chip = v;
 	void *ret = NULL;
 
+	spin_lock_irqsave(&gpio_lock, flags);
 	if (list_is_last(&chip->list, &gpio_chips))
 		ret = NULL;
 	else
 		ret = list_entry(chip->list.next, struct gpio_chip, list);
+	spin_unlock_irqrestore(&gpio_lock, flags);
 
 	s->private = "\n";
 	++*pos;
-- 
1.7.10.4

Re: [PATCH] gpiolib: Fix locking on gpio debugfs files

[Alex Courbot]

On 02/09/2013 07:34 PM, Grant Likely wrote:
> The debugfs files really need to hold the gpiolib spinlock before
> accessing the list. Otherwise chip addition/removal will cause an oops.
>
> Cc: Alexandre Courbot <acourbot@nvidia.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

Tested-by: Alexandre Courbot <acourbot@nvidia.com>

Just wondering: if we manage to change this spinlock into a mutex in the 
future, wouldn't it be better to acquire it only once in 
gpiolib_seq_start() and release it in gpiolib_seq_stop()?

Even though the protection introduced by this patch definitely improves 
the situation, it seems to me that chips could still be removed while 
being displayed by gpiolib_seq_show().

Thanks,
Alex.

Re: [PATCH] gpiolib: Fix locking on gpio debugfs files

[Grant Likely]

On Mon, Feb 11, 2013 at 4:28 AM, Alex Courbot <acourbot@nvidia.com> wrote:
> On 02/09/2013 07:34 PM, Grant Likely wrote:
>>
>> The debugfs files really need to hold the gpiolib spinlock before
>> accessing the list. Otherwise chip addition/removal will cause an oops.
>>
>> Cc: Alexandre Courbot <acourbot@nvidia.com>
>> Cc: Linus Walleij <linus.walleij@linaro.org>
>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>
>
> Tested-by: Alexandre Courbot <acourbot@nvidia.com>
>
> Just wondering: if we manage to change this spinlock into a mutex in the
> future, wouldn't it be better to acquire it only once in gpiolib_seq_start()
> and release it in gpiolib_seq_stop()?
>
> Even though the protection introduced by this patch definitely improves the
> situation, it seems to me that chips could still be removed while being
> displayed by gpiolib_seq_show().

Probably, but need to first verify that the mutex won't end up getting
held between read() syscalls. Otherwise it would be possible to block
addition/removal by holding the file open. I cursory read of seq_file
looks like ->stop() is always called, but I would appreciate someone
more cluefull to give an opinion here.

I've also got a draft patch that turns gpio chips into first-class
kobjects which means we can do proper reference counting on them and
prevent the structure from actually disappearing while other drivers
still hold references.

g.

Re: [PATCH] gpiolib: Fix locking on gpio debugfs files

[Alexandre Courbot]

On Mon, Feb 11, 2013 at 8:31 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Mon, Feb 11, 2013 at 4:28 AM, Alex Courbot <acourbot@nvidia.com> wrote:
>> Just wondering: if we manage to change this spinlock into a mutex in the
>> future, wouldn't it be better to acquire it only once in gpiolib_seq_start()
>> and release it in gpiolib_seq_stop()?
>>
>> Even though the protection introduced by this patch definitely improves the
>> situation, it seems to me that chips could still be removed while being
>> displayed by gpiolib_seq_show().
>
> Probably, but need to first verify that the mutex won't end up getting
> held between read() syscalls. Otherwise it would be possible to block
> addition/removal by holding the file open. I cursory read of seq_file
> looks like ->stop() is always called, but I would appreciate someone
> more cluefull to give an opinion here.

While not cluefull in any way, I nonetheless had a quick look at all
the control paths of seq_read(), and indeed op->stop() seems to be
called in each of them.

> I've also got a draft patch that turns gpio chips into first-class
> kobjects which means we can do proper reference counting on them and
> prevent the structure from actually disappearing while other drivers
> still hold references.

Oooh. Looking forward to seeing this. :)

Alex.

Re: [PATCH] gpiolib: Fix locking on gpio debugfs files

[Linus Walleij]

On Sat, Feb 9, 2013 at 11:34 AM, Grant Likely <grant.likely@secretlab.ca> wrote:

> The debugfs files really need to hold the gpiolib spinlock before
> accessing the list. Otherwise chip addition/removal will cause an oops.
>
> Cc: Alexandre Courbot <acourbot@nvidia.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

Acked-by: Linus Walleij <linus.walleij@linaro.org>

> I've also got a draft patch that turns gpio chips into first-class
> kobjects which means we can do proper reference counting on them and
> prevent the structure from actually disappearing while other drivers
> still hold references.

Thank you for doing this!

Yours,
Linus Walleij