* [PATCH] gpiolib: Fix locking on gpio debugfs files
@ 2013-02-09 10:34 Grant Likely
2013-02-11 4:28 ` Alex Courbot
2013-02-11 14:31 ` Linus Walleij
0 siblings, 2 replies; 5+ messages in thread
From: Grant Likely @ 2013-02-09 10:34 UTC (permalink / raw)
To: linux-kernel; +Cc: Grant Likely, Alexandre Courbot, Linus Walleij
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
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] gpiolib: Fix locking on gpio debugfs files
2013-02-09 10:34 [PATCH] gpiolib: Fix locking on gpio debugfs files Grant Likely
@ 2013-02-11 4:28 ` Alex Courbot
2013-02-11 11:31 ` Grant Likely
2013-02-11 14:31 ` Linus Walleij
1 sibling, 1 reply; 5+ messages in thread
From: Alex Courbot @ 2013-02-11 4:28 UTC (permalink / raw)
To: Grant Likely; +Cc: linux-kernel, Linus Walleij, Alexandre 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] gpiolib: Fix locking on gpio debugfs files
2013-02-11 4:28 ` Alex Courbot
@ 2013-02-11 11:31 ` Grant Likely
2013-02-12 2:27 ` Alexandre Courbot
0 siblings, 1 reply; 5+ messages in thread
From: Grant Likely @ 2013-02-11 11:31 UTC (permalink / raw)
To: Alex Courbot; +Cc: linux-kernel, Linus Walleij, Alexandre Courbot
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] gpiolib: Fix locking on gpio debugfs files
2013-02-09 10:34 [PATCH] gpiolib: Fix locking on gpio debugfs files Grant Likely
2013-02-11 4:28 ` Alex Courbot
@ 2013-02-11 14:31 ` Linus Walleij
1 sibling, 0 replies; 5+ messages in thread
From: Linus Walleij @ 2013-02-11 14:31 UTC (permalink / raw)
To: Grant Likely; +Cc: linux-kernel, Alexandre Courbot
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] gpiolib: Fix locking on gpio debugfs files
2013-02-11 11:31 ` Grant Likely
@ 2013-02-12 2:27 ` Alexandre Courbot
0 siblings, 0 replies; 5+ messages in thread
From: Alexandre Courbot @ 2013-02-12 2:27 UTC (permalink / raw)
To: Grant Likely; +Cc: linux-kernel, Linus Walleij, 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-02-12 2:28 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-09 10:34 [PATCH] gpiolib: Fix locking on gpio debugfs files Grant Likely
2013-02-11 4:28 ` Alex Courbot
2013-02-11 11:31 ` Grant Likely
2013-02-12 2:27 ` Alexandre Courbot
2013-02-11 14:31 ` Linus Walleij
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).