All of lore.kernel.org
 help / color / mirror / Atom feed
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC v3 3/3] pinctrl: add pinctrl gpio binding support
Date: Thu, 24 May 2012 22:59:47 -0600	[thread overview]
Message-ID: <4FBF11C3.3030207@wwwdotorg.org> (raw)
In-Reply-To: <20120525032250.GA13524@shlinux2.ap.freescale.net>

On 05/24/2012 09:22 PM, Dong Aisheng wrote:
> On Thu, May 24, 2012 at 11:22:13PM +0800, Stephen Warren wrote:
...
>> The problem is this:
>>
>> Thread 1: Call of_node_to_gpiochip(), returns a gpio_chip.
>> Thread 2: Unregisters the same gpio_chip that was returned above.
>> Thread 1: Accesses the now unregistered (and possibly free'd) gpio_chip
>> -> at best, bad data, at worst, OOPS.
>>
> Correct. We did have this issue.
> Thanks for clarify.
> 
>> In order to prevent this, of_node_to_gpiochip() should take measures to
>> prevent another thread from unregistering the gpio_chip until thread 1
>> has completed its step above.
>>
>> The existing of_get_named_gpio_flags() is safe from this, since
>> gpiochip_find() acquires the GPIO lock, and all accesses to the fouond
>> gpio chip occur with that lock held, inside the match function. Perhaps
>> a similar approach could be used here.
>
> Why it looks to me of_get_named_gpio_flags has the same issue and also not safe?
> For of_node_to_gpiochip itself called in of_get_named_gpio_flags, it's safe.

Uggh. Yes, I meant that of_node_to_gpiochip() itself doesn't have this
issue, but you're right, it looks like of_get_named_gpio_flags() does.

> But after that, i'm suspecting it has the same issue as you described above, right?
> 
> For example:
> int of_get_named_gpio_flags(struct device_node *np, const char *propname,
>                            int index, enum of_gpio_flags *flags)
> {
> ...
> 	gc = of_node_to_gpiochip(gpiospec.np);
> 	if (!gc) {
> 		pr_debug("%s: gpio controller %s isn't registered\n",
> 			 np->full_name, gpiospec.np->full_name);
> 		ret = -ENODEV;
> 		goto err1;
> 	}
> 
> 	===> the gc may be unregistered here by another thread and
> 	     even already have been freed, right?
> 
> 	ret = gc->of_xlate(gc, &gpiospec, flags);
> ...
> }
> 
> Maybe we need get the lock in of_node_to_gpiochip and release it by calling
> of_gpio_put(..) after using?

Yes, something like that; it should take the module lock, not the gpio lock.

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Warren <swarren@wwwdotorg.org>
To: Dong Aisheng <aisheng.dong@freescale.com>
Cc: Dong Aisheng-B29396 <B29396@freescale.com>,
	Dong Aisheng <dongas86@gmail.com>,
	Grant Likely <grant.likely@secretlab.ca>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linus.walleij@stericsson.com" <linus.walleij@stericsson.com>,
	devicetree-discuss <devicetree-discuss@lists.ozlabs.org>,
	Rob Herring <rob.herring@calxeda.com>
Subject: Re: [PATCH RFC v3 3/3] pinctrl: add pinctrl gpio binding support
Date: Thu, 24 May 2012 22:59:47 -0600	[thread overview]
Message-ID: <4FBF11C3.3030207@wwwdotorg.org> (raw)
In-Reply-To: <20120525032250.GA13524@shlinux2.ap.freescale.net>

On 05/24/2012 09:22 PM, Dong Aisheng wrote:
> On Thu, May 24, 2012 at 11:22:13PM +0800, Stephen Warren wrote:
...
>> The problem is this:
>>
>> Thread 1: Call of_node_to_gpiochip(), returns a gpio_chip.
>> Thread 2: Unregisters the same gpio_chip that was returned above.
>> Thread 1: Accesses the now unregistered (and possibly free'd) gpio_chip
>> -> at best, bad data, at worst, OOPS.
>>
> Correct. We did have this issue.
> Thanks for clarify.
> 
>> In order to prevent this, of_node_to_gpiochip() should take measures to
>> prevent another thread from unregistering the gpio_chip until thread 1
>> has completed its step above.
>>
>> The existing of_get_named_gpio_flags() is safe from this, since
>> gpiochip_find() acquires the GPIO lock, and all accesses to the fouond
>> gpio chip occur with that lock held, inside the match function. Perhaps
>> a similar approach could be used here.
>
> Why it looks to me of_get_named_gpio_flags has the same issue and also not safe?
> For of_node_to_gpiochip itself called in of_get_named_gpio_flags, it's safe.

Uggh. Yes, I meant that of_node_to_gpiochip() itself doesn't have this
issue, but you're right, it looks like of_get_named_gpio_flags() does.

> But after that, i'm suspecting it has the same issue as you described above, right?
> 
> For example:
> int of_get_named_gpio_flags(struct device_node *np, const char *propname,
>                            int index, enum of_gpio_flags *flags)
> {
> ...
> 	gc = of_node_to_gpiochip(gpiospec.np);
> 	if (!gc) {
> 		pr_debug("%s: gpio controller %s isn't registered\n",
> 			 np->full_name, gpiospec.np->full_name);
> 		ret = -ENODEV;
> 		goto err1;
> 	}
> 
> 	===> the gc may be unregistered here by another thread and
> 	     even already have been freed, right?
> 
> 	ret = gc->of_xlate(gc, &gpiospec, flags);
> ...
> }
> 
> Maybe we need get the lock in of_node_to_gpiochip and release it by calling
> of_gpio_put(..) after using?

Yes, something like that; it should take the module lock, not the gpio lock.

  reply	other threads:[~2012-05-25  4:59 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-23 13:22 [PATCH RFC v3 1/3] pinctrl: remove pinctrl_remove_gpio_range Dong Aisheng
2012-05-23 13:22 ` Dong Aisheng
2012-05-23 13:22 ` [PATCH RFC v3 2/3] pinctrl: add pinctrl_add_gpio_ranges function Dong Aisheng
2012-05-23 13:22   ` Dong Aisheng
2012-05-24 15:02   ` Linus Walleij
2012-05-24 15:02     ` Linus Walleij
2012-05-23 13:22 ` [PATCH RFC v3 3/3] pinctrl: add pinctrl gpio binding support Dong Aisheng
2012-05-23 13:22   ` Dong Aisheng
2012-05-23 13:30   ` Dong Aisheng
2012-05-23 13:30     ` Dong Aisheng
2012-05-23 20:44   ` Stephen Warren
2012-05-23 20:44     ` Stephen Warren
2012-05-24  1:42     ` Dong Aisheng
2012-05-24  1:42       ` Dong Aisheng
2012-05-24  4:42       ` Stephen Warren
2012-05-24  4:42         ` Stephen Warren
2012-05-24  5:19         ` Dong Aisheng
2012-05-24  5:19           ` Dong Aisheng
2012-05-24 15:22           ` Stephen Warren
2012-05-24 15:22             ` Stephen Warren
2012-05-24 15:22             ` Stephen Warren
2012-05-25  3:22             ` Dong Aisheng
2012-05-25  3:22               ` Dong Aisheng
2012-05-25  3:22               ` Dong Aisheng
2012-05-25  4:59               ` Stephen Warren [this message]
2012-05-25  4:59                 ` Stephen Warren
2012-05-25  5:09                 ` Dong Aisheng
2012-05-25  5:09                   ` Dong Aisheng
2012-05-25  5:09                   ` Dong Aisheng
2012-05-23 20:29 ` [PATCH RFC v3 1/3] pinctrl: remove pinctrl_remove_gpio_range Stephen Warren
2012-05-23 20:29   ` Stephen Warren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FBF11C3.3030207@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.