[PATCH 1/5] check for proper registration with device core

[Russell King]

On Tue, May 11, 2004 at 09:28:29PM +0200, Dominik Brodowski wrote:
> Fail if registration of socket with driver core failed. This is necessary
> so that socket-related sysfs entries will appear always if a socket thread
> is up and running.

Ok, if we're going to make this change, I want to hear _success_ reports
for each of the following cases (and I shall be ticking them off):

- non-modular, pcmcia card in socket during boot
- non-modular, pcmcia card inserted after boot
- non-modular, cardbus card in socket during boot
- non-modular, cardbus card inserted after boot
- modular, pcmcia card in socket during boot/module insertion
- modular, pcmcia card inserted after boot/module insertion
- modular, cardbus card in socket during boot/module insertion
- modular, cardbus card inserted after boot/module insertion

In the past, we've had _lots_ of problems with this and I want to make
reasonably sure that we don't re-introduce either the PCMCIA vs SYSFS
deadlocks or the PCMCIA card initialisation race condition.

Here's the original problem:

http://lists.infradead.org/pipermail/linux-pcmcia/2003-September/000232.html

and the fix for this was to introduce skt_sem into pcmcia_register_client
(cs.c 1.58).  However, this promptly caused the following deadlock:

insmod        D C003AC98 28008860   446    422                     (NOTLB)
[<c003a9fc>] (schedule+0x0/0x368)
[<c002b4a0>] (__down+0x0/0x108)
[<bf0059bc>] (pcmcia_register_client+0x0/0x288 [pcmcia_core])
[<bf012458>] (pcmcia_bus_add_socket+0x0/0x168 [ds])
[<c00f5c48>] (class_device_add+0x0/0x10c)
[<bf00395c>] (pcmcia_register_socket+0x0/0x160 [pcmcia_core])
[<bf016558>] (yenta_probe+0x0/0x238 [yenta_socket])
[<c00cbc14>] (pci_device_probe_static+0x0/0x68)
[<c00cbd64>] (__pci_device_probe+0x0/0x58)
[<c00cbdbc>] (pci_device_probe+0x0/0x44)
[<c00f50b8>] (bus_match+0x0/0x70)
[<c00f51b8>] (driver_attach+0x0/0x80)
[<c00f53d0>] (bus_add_driver+0x0/0x84)
[<c00f5710>] (driver_register+0x0/0x40)
[<c00cc018>] (pci_register_driver+0x0/0x88)
[<c0053a00>] (sys_init_module+0x0/0x308)
pccardd       D C003AC98 4290282060   448      1                 418 (L-TLB)
[<c003a9fc>] (schedule+0x0/0x368)
[<c00c3de8>] (__down_write+0x0/0x98)
[<c00f52e0>] (bus_add_device+0x0/0x7c)
[<c00f4454>] (device_add+0x0/0xe4)
[<c00c8800>] (pci_bus_add_devices+0x0/0xf4)
[<bf0092e8>] (cb_alloc+0x0/0xd0 [pcmcia_core])
[<bf0042b0>] (socket_insert+0x0/0x1ec [pcmcia_core])
[<bf004694>] (socket_detect_change+0x0/0x90 [pcmcia_core])
[<bf004724>] (pccardd+0x0/0x178 [pcmcia_core])

The insmod process has inserted yenta.  Since it's a PCI driver, the
pci_bus_type semaphore is locked while the driver initialises.  It
called pcmcia_register_socket, which in turn has called class_device_add.
This passed control over to ds which registered itself as a client for
the socket, sleeping on skt->sem.

Meanwhile, pccardd was spawned, and successfully claimed skt->sem.  It
found a cardbus card in the socket, and attempted to register it with
the PCI subsystem.  The PCI subsystem tried to take the pci_bus_type
semaphore.

*DEADLOCK*.

I want to be sure that we're not introducing a deadlock like this in
with a change which alters the initialisation behaviour.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core