[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100320212501.138b1644@hyperion.delvare>
Date: Sat, 20 Mar 2010 21:25:01 +0100
From: Jean Delvare <khali@...ux-fr.org>
To: Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc: Wolfram Sang <w.sang@...gutronix.de>,
kernel-janitors@...r.kernel.org, linux-i2c@...r.kernel.org,
linux-kernel@...r.kernel.org, Samuel Ortiz <sameo@...ux.intel.com>
Subject: Re: [PATCH 13/24] mfd: fix dangling pointers
On Sat, 20 Mar 2010 17:22:41 +0000, Mark Brown wrote:
> On Sat, Mar 20, 2010 at 03:12:54PM +0100, Wolfram Sang wrote:
> > Fix I2C-drivers which missed setting clientdata to NULL before freeing the
> > structure it points to. Also fix drivers which do this _after_ the structure
> > was freed already.
>
> Acked-by: Mark Brown <broonie@...nsource.wolfsonmicro.com>
>
> but it really does seem like this is something that the I2C core ought
> to handle - the assignment to null is boiler plate code that's getting
> added to the overwhelming majority of I2C devices in their teardown
> path, it'd seem a lot more sensible for the core to just trash driver
> data after the driver is unbound if it's important that this happens.
This is an interesting point. Do you know of any other subsystem doing
this? The core touching private data seems wrong to me, but I have to
agree that it would avoid a lot of duplication across drivers.
Can someone find a reasonable use case for client data surviving the
driver's .remove() call?
--
Jean Delvare
--
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