[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20110331191538.27afef9a@schatten.dmk.lab>
Date: Thu, 31 Mar 2011 19:15:38 +0200
From: Florian Mickler <florian@...kler.org>
To: "Justin P. Mattock" <justinmattock@...il.com>
Cc: linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>,
Manjunatha Halli <manjunatha_halli@...com>,
Mauro Carvalho Chehab <mchehab@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...e.de>
Subject: Re: [BUG] NULL pointer dereference in dev_get_drvdata
On Thu, 31 Mar 2011 08:41:53 -0700
"Justin P. Mattock" <justinmattock@...il.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists