mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Florian Mickler <florian@mickler.org>
To: "Justin P. Mattock" <justinmattock@gmail.com>
Cc: linux-kernel@vger.kernel.org,
	Steven Rostedt <rostedt@goodmis.org>,
	Manjunatha Halli <manjunatha_halli@ti.com>,
	Mauro Carvalho Chehab <mchehab@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Greg Kroah-Hartman <gregkh@suse.de>
Subject: Re: [BUG] NULL pointer dereference in dev_get_drvdata
Date: Thu, 31 Mar 2011 19:15:38 +0200	[thread overview]
Message-ID: <20110331191538.27afef9a@schatten.dmk.lab> (raw)
In-Reply-To: <4D94A0C1.1060608@gmail.com>

On Thu, 31 Mar 2011 08:41:53 -0700
"Justin P. Mattock" <justinmattock@gmail.com> wrote:

> >
> two drivers calling the same function(sounds bad!) this would be a race 
> condition right?

No. A race is about data. While many races involve the same function
beeing called multiple times in parallel, it is not necessary. It may
well be two seperate functions accessing the same data. 

Also you can of course have two functions doing the same thing to
different data. Just look at dev_get_drvdata... 

void *dev_get_drvdata(const struct device *dev)
{
        if (dev && dev->p)
                return dev->p->driver_data;
        return NULL;
}


it just returns a memory address relativ to the *dev pointer given to
it.  So if you call it multiple times in parallel with different *dev
pointers, nothing happens. 

In fact, dev_get_drvdata is read only, so it alone can never cause any
race. (Except in some obscure on-stack dma setups which are broken,
uncommen and avoided)

For dev_get_drvdata to be part of a race, you would have (for example)
something setting dev->p to NULL in parallel. 

That way, if that something gets to execute between the 

	if (dev && dev->p) 

line and the 
		return dev->p->driver_data;

then, that would be bad, because dev_get_drvdata would have already
decided that that if is true.... 

 
> As for this message I will keep my eye out for anything in this area and 
> report it to you guys.

But please if you put up fotos, try to have a pixel:character quota of
more then 3 ... and also remember, the stacktrace is
almost always the important part of the warning.

Regards,
Flo

      reply	other threads:[~2011-03-31 17:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-30  1:28 Steven Rostedt
2011-03-30  1:59 ` Mauro Carvalho Chehab
2011-03-30  2:17   ` Steven Rostedt
2011-03-30 15:47 ` Justin P. Mattock
2011-03-31  9:16   ` Florian Mickler
2011-03-31 15:41     ` Justin P. Mattock
2011-03-31 17:15       ` Florian Mickler [this message]

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=20110331191538.27afef9a@schatten.dmk.lab \
    --to=florian@mickler.org \
    --cc=akpm@linux-foundation.org \
    --cc=gregkh@suse.de \
    --cc=justinmattock@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manjunatha_halli@ti.com \
    --cc=mchehab@redhat.com \
    --cc=rostedt@goodmis.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome