On Mon, Jan 20, 2014 at 04:26:23PM -0800, Greg KH wrote:
> On Tue, Jan 21, 2014 at 12:07:06AM +0000, Russell King - ARM Linux wrote:
> > On Mon, Jan 20, 2014 at 03:51:28PM -0800, Greg KH wrote:
> > > On Mon, Jan 20, 2014 at 11:16:03PM +0000, Russell King - ARM Linux wrote:
> > > > I don't believe the driver model has any locking to prevent a drivers
> > > > ->probe function running concurrently with it's ->remove function for
> > > > two (or more) devices.
> > >
> > > The bus prevents this from happening.
> > >
> > > > The locking against this is done on a per-device basis, not a per-driver
> > > > basis.
> > >
> > > No, on a per-bus basis.
> >
> > I don't see it.
> >
> > Let's start from driver_register().
>
> Which happens from module probing, which is single-threaded, right?
Yes, to _some_ extent - the driver is added to the bus list of drivers
before existing drivers are probed, so it's always worth bearing in
mind that if a new device comes along, it's possible for that device
to be offered to even a driver which hasn't finished returning from
its module_init().
> > If you think there's a per-driver lock that's held over probes or removes,
> > please point it out. I'm fairly certain that there isn't, because we have
> > to be able to deal with recursive probes (yes, we've had to deal with
> > those in the past.)
>
> Hm, you are right, I think that's why we had to remove the locks. The
> klist stuff handles us getting the needed locks for managing our
> internal lists of devices and drivers, and those should be fine.
>
> So, let's go back to your original worry, what are you concerned about?
> A device being removed while probe() is called?
My concern is that we're turning something which should be simple into
something unnecessarily complex. By that, I mean something along the
lines of:
static DEFINE_MUTEX(foo_mutex);
static unsigned foo_devices;
static int foo_probe(struct platform_device *pdev)
{
int ret;
mutex_lock(&foo_mutex);
if (foo_devices++ == 0)
uart_register_driver(&driver);
ret = foo_really_probe_device(pdev);
if (ret) {
if (--foo_devices == 0)
uart_unregister_driver(&driver);
}
mutex_unlock(&foo_mutex);
return ret;
}
static int foo_remove(struct platform_device *pdev)
{
mutex_lock(&foo_mutex);
foo_really_remove(pdev);
if (--foo_devices == 0)
uart_unregister_driver(&driver);
mutex_unlock(&foo_mutex);
return 0;
}
in every single serial driver we have... Wouldn't it just be better to
fix the major/minor number problem rather than have to add all that code
repetitively to all those drivers?
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
