Re: [PATCH 2/2] serial: pl011: Move uart_register_driver call to device probe

[One Thousand Gnomes]

> > The race isn't the uart code, it's the driver model.
> > 
> > Consider what happens when this happens:
> > 
> > * Two pl011 devices get registered at the same time by two different
> >   threads.
> 
> How?  What two different busses will see this same device?  The amba bus
> code should prevent that from happening, right?  If not, there's bigger
> problems in that bus code :)
> 
> That's where this problem should be fixed, if there is one, otherwise
> this same issue would be there for any type of driver that calles into
> the uart core, right?

I did some more digging into this the problem goes beyond the uart and
driver model code. Even if you serialize every bus and you serialize
every bus against every other bus (which you can't do btw as we get
recursive probes of one bus from a device probe of another) it's still
racy. We have non bus registering paths for some drivers and those could
be user triggered.

An obvious example is 8250.

If the 8250 driver is loaded on a platform where no device is
autodetected (which is true on a few wackier PC laptops with touchscreens
on an 8250) then you hae a race between say a PCMCIA card insertion of an
8250 and a user who creates the first 8250 device using setserial at the
same moment.

There are similar races between the various directly created devices on
some of the serial ports and bus probed ones where the driver mixes bus
probing with olde worlde straight forward hardcoding.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/