On Mon, Nov 02, 2015 at 01:06:33PM +0000, Mark Brown wrote:
> On Mon, Nov 02, 2015 at 01:53:47PM +0100, Johan Hovold wrote:
> > On Mon, Nov 02, 2015 at 12:47:37PM +0000, Mark Brown wrote:
>
> > > A memset() should be enough, if not then we have problems with any
> > > dynamically allocated struct device.
>
> > And how would you know that it is safe to memset that struct device?
> > There can still be references to it. And driver core explicitly forbids
> > this (see device_add() for example).
>
> My point here is that the memset() of something that was passed in
> externally isn't really a problem, it's the suspicious lack of
> integration with a release function (hence my question about why the
> driver core isn't complaining when the device gets registered). The
> comment is more of a concern than the memset() itself.
Precisely, the memset itself is not the problem, but rather why was done
in the first place:
* We memset the struct to zero to avoid reentrance issues.
*/
And to that point, I mentioned that it is illegal to register the same
struct device twice (and that this was indicative of a larger problem).
> > Dynamically allocated struct device are not the problem as then you're
> > not *reusing* the same device structure.
>
> You may end up doing exactly that depending on what you get back from
> the allocator of course.
But then the memory has already been released. You're not deregistering
and reregistering the same device as in your example.
> The point is to make sure that that the driver
> model called release(), dynamically allocating and freeing in the
> release function is the easiest way to do this but it's not magic.
Agreed.
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
