[2.6 patch] remove the broken PCI_MULTITHREAD_PROBE option

[2.6 patch] remove the broken PCI_MULTITHREAD_PROBE option

[Adrian Bunk]

This patch removes the PCI_MULTITHREAD_PROBE option that had already 
been marked as broken.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 Documentation/pci.txt    |    4 ---
 drivers/base/dd.c        |   41 ++-------------------------------------
 drivers/pci/Kconfig      |   25 -----------------------
 drivers/pci/pci-driver.c |   15 --------------
 include/linux/device.h   |    1 
 5 files changed, 3 insertions(+), 83 deletions(-)

--- linux-2.6.21-rc4-mm1/drivers/pci/Kconfig.old	2007-03-26 21:14:09.000000000 +0200
+++ linux-2.6.21-rc4-mm1/drivers/pci/Kconfig	2007-03-26 21:14:17.000000000 +0200
@@ -17,31 +17,6 @@
 
 	   If you don't know what to do here, say N.
 
-config PCI_MULTITHREAD_PROBE
-	bool "PCI Multi-threaded probe (EXPERIMENTAL)"
-	depends on PCI && EXPERIMENTAL && BROKEN
-	help
-	  Say Y here if you want the PCI core to spawn a new thread for
-	  every PCI device that is probed.  This can cause a huge
-	  speedup in boot times on multiprocessor machines, and even a
-	  smaller speedup on single processor machines.
-
-	  But it can also cause lots of bad things to happen.  A number
-	  of PCI drivers cannot properly handle running in this way,
-	  some will just not work properly at all, while others might
-	  decide to blow up power supplies with a huge load all at once,
-	  so use this option at your own risk.
-
-	  It is very unwise to use this option if you are not using a
-	  boot process that can handle devices being created in any
-	  order.  A program that can create persistent block and network
-	  device names (like udev) is a good idea if you wish to use
-	  this option.
-
-	  Again, use this option at your own risk, you have been warned!
-
-	  When in doubt, say N.
-
 config PCI_DEBUG
 	bool "PCI Debugging"
 	depends on PCI && DEBUG_KERNEL
--- linux-2.6.21-rc4-mm1/Documentation/pci.txt.old	2007-03-26 21:33:53.000000000 +0200
+++ linux-2.6.21-rc4-mm1/Documentation/pci.txt	2007-03-26 21:34:01.000000000 +0200
@@ -124,10 +124,6 @@
 
 	err_handler	See Documentation/pci-error-recovery.txt
 
-	multithread_probe	Enable multi-threaded probe/scan. Driver must
-			provide its own locking/syncronization for init
-			operations if this is enabled.
-
 
 The ID table is an array of struct pci_device_id entries ending with an
 all-zero entry.  Each entry consists of:
--- linux-2.6.21-rc4-mm1/include/linux/device.h.old	2007-03-26 21:33:30.000000000 +0200
+++ linux-2.6.21-rc4-mm1/include/linux/device.h	2007-03-26 21:33:39.000000000 +0200
@@ -80,7 +80,6 @@
 	int (*resume)(struct device * dev);
 
 	unsigned int drivers_autoprobe:1;
-	unsigned int multithread_probe:1;
 };
 
 extern int __must_check bus_register(struct bus_type * bus);
--- linux-2.6.21-rc4-mm1/drivers/pci/pci-driver.c.old	2007-03-26 21:29:05.000000000 +0200
+++ linux-2.6.21-rc4-mm1/drivers/pci/pci-driver.c	2007-03-26 21:31:00.000000000 +0200
@@ -14,20 +14,6 @@
 #include "pci.h"
 
 /*
- *  Registration of PCI drivers and handling of hot-pluggable devices.
- */
-
-/* multithreaded probe logic */
-static int pci_multithread_probe =
-#ifdef CONFIG_PCI_MULTITHREAD_PROBE
-	1;
-#else
-	0;
-#endif
-__module_param_call("", pci_multithread_probe, param_set_bool, param_get_bool, &pci_multithread_probe, 0644);
-
-
-/*
  * Dynamic device IDs are disabled for !CONFIG_HOTPLUG
  */
 
@@ -569,7 +555,6 @@
 
 static int __init pci_driver_init(void)
 {
-	pci_bus_type.multithread_probe = pci_multithread_probe;
 	return bus_register(&pci_bus_type);
 }
 
--- linux-2.6.21-rc4-mm1/drivers/base/dd.c.old	2007-03-26 21:35:00.000000000 +0200
+++ linux-2.6.21-rc4-mm1/drivers/base/dd.c	2007-03-26 21:38:58.000000000 +0200
@@ -226,12 +226,10 @@
  *
  *	Walk the list of drivers that the bus has and call
  *	driver_probe_device() for each pair. If a compatible
- *	pair is found, break out and return. If the bus specifies
- *	multithreaded probing, walking the list of drivers is done
- *	on a probing thread.
+ *	pair is found, break out and return.
  *
  *	Returns 1 if the device was bound to a driver;
- *	0 if no matching device was found or multithreaded probing is done;
+ *	0 if no matching device was found;
  *	-ENODEV if the device is not registered.
  *
  *	When called for a USB interface, @dev->parent->sem must be held.
@@ -239,7 +237,6 @@
 int device_attach(struct device * dev)
 {
 	int ret = 0;
-	struct task_struct *probe_task = ERR_PTR(-ENOMEM);
 
 	down(&dev->sem);
 	if (dev->driver) {
@@ -251,12 +248,7 @@
 			ret = 0;
 		}
 	} else {
-		if (dev->bus->multithread_probe)
-			probe_task = kthread_run(device_probe_drivers, dev,
-						 "probe-%s", dev->bus_id);
-		if(IS_ERR(probe_task))
-			ret = bus_for_each_drv(dev->bus, NULL, dev,
-					       __device_attach);
+		ret = bus_for_each_drv(dev->bus, NULL, dev, __device_attach);
 	}
 	up(&dev->sem);
 	return ret;
@@ -383,33 +375,6 @@
 	}
 }
 
-#ifdef CONFIG_PCI_MULTITHREAD_PROBE
-static int __init wait_for_probes(void)
-{
-	DEFINE_WAIT(wait);
-
-	printk(KERN_INFO "%s: waiting for %d threads\n", __FUNCTION__,
-			atomic_read(&probe_count));
-	if (!atomic_read(&probe_count))
-		return 0;
-	while (atomic_read(&probe_count)) {
-		prepare_to_wait(&probe_waitqueue, &wait, TASK_UNINTERRUPTIBLE);
-		if (atomic_read(&probe_count))
-			schedule();
-	}
-	finish_wait(&probe_waitqueue, &wait);
-	return 0;
-}
-
-core_initcall_sync(wait_for_probes);
-postcore_initcall_sync(wait_for_probes);
-arch_initcall_sync(wait_for_probes);
-subsys_initcall_sync(wait_for_probes);
-fs_initcall_sync(wait_for_probes);
-device_initcall_sync(wait_for_probes);
-late_initcall_sync(wait_for_probes);
-#endif
-
 EXPORT_SYMBOL_GPL(device_bind_driver);
 EXPORT_SYMBOL_GPL(device_release_driver);
 EXPORT_SYMBOL_GPL(device_attach);

Re: [2.6 patch] remove the broken PCI_MULTITHREAD_PROBE option

[Cornelia Huck]

On Tue, 27 Mar 2007 03:02:51 +0200,
Adrian Bunk <bunk@stusta.de> wrote:

> This patch removes the PCI_MULTITHREAD_PROBE option that had already 
> been marked as broken.
> 
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
> 
> ---
> 
>  Documentation/pci.txt    |    4 ---
>  drivers/base/dd.c        |   41 ++-------------------------------------
>  drivers/pci/Kconfig      |   25 -----------------------
>  drivers/pci/pci-driver.c |   15 --------------
>  include/linux/device.h   |    1 
>  5 files changed, 3 insertions(+), 83 deletions(-)

Greg, what about driver-core-per-subsystem-multithreaded-probing.patch?
PCI_MULTITHREAD_PROBE shoudn't be broken with that, only in mainline?

Re: [2.6 patch] remove the broken PCI_MULTITHREAD_PROBE option

[Greg KH]

On Tue, Mar 27, 2007 at 01:03:51PM +0200, Cornelia Huck wrote:
> On Tue, 27 Mar 2007 03:02:51 +0200,
> Adrian Bunk <bunk@stusta.de> wrote:
> 
> > This patch removes the PCI_MULTITHREAD_PROBE option that had already 
> > been marked as broken.
> > 
> > Signed-off-by: Adrian Bunk <bunk@stusta.de>
> > 
> > ---
> > 
> >  Documentation/pci.txt    |    4 ---
> >  drivers/base/dd.c        |   41 ++-------------------------------------
> >  drivers/pci/Kconfig      |   25 -----------------------
> >  drivers/pci/pci-driver.c |   15 --------------
> >  include/linux/device.h   |    1 
> >  5 files changed, 3 insertions(+), 83 deletions(-)
> 
> Greg, what about driver-core-per-subsystem-multithreaded-probing.patch?
> PCI_MULTITHREAD_PROBE shoudn't be broken with that, only in mainline?

Do you want to enable PCI multithreaded probing using your patch?  I
don't think the world is ready for pci multithreaded probing as was
determined by the zillion of bug reports from people who like to enable
config options that state in big letters, "THIS WILL BREAK YOUR BOX"...

And I'm still questioning if we should add your patch at all, as I don't
think any other subsystems need it.  Do you?

thanks,

greg k-h

Re: [2.6 patch] remove the broken PCI_MULTITHREAD_PROBE option

[Cornelia Huck]

On Tue, 27 Mar 2007 15:50:06 -0700,
Greg KH <greg@kroah.com> wrote:

> > Greg, what about driver-core-per-subsystem-multithreaded-probing.patch?
> > PCI_MULTITHREAD_PROBE shoudn't be broken with that, only in mainline?
> 
> Do you want to enable PCI multithreaded probing using your patch?  I
> don't think the world is ready for pci multithreaded probing as was
> determined by the zillion of bug reports from people who like to enable
> config options that state in big letters, "THIS WILL BREAK YOUR BOX"...

But IIRC, that was without my patch? Wouldn't per-subsystem
multithreaded probing just expose bugs that could also be exposed on
SMP systems?

> And I'm still questioning if we should add your patch at all, as I don't
> think any other subsystems need it.  Do you?

The css/ccw busses may profit from it, since we tend to have thousands
of devices there. OTOH, we've already tried to make probing as
asynchronous as possible, so maybe there isn't that much gain. I'd need
to do some measurements (when I find some time...)

Re: [2.6 patch] remove the broken PCI_MULTITHREAD_PROBE option

[Greg KH]

On Wed, Mar 28, 2007 at 10:36:25AM +0200, Cornelia Huck wrote:
> On Tue, 27 Mar 2007 15:50:06 -0700,
> Greg KH <greg@kroah.com> wrote:
> 
> > > Greg, what about driver-core-per-subsystem-multithreaded-probing.patch?
> > > PCI_MULTITHREAD_PROBE shoudn't be broken with that, only in mainline?
> > 
> > Do you want to enable PCI multithreaded probing using your patch?  I
> > don't think the world is ready for pci multithreaded probing as was
> > determined by the zillion of bug reports from people who like to enable
> > config options that state in big letters, "THIS WILL BREAK YOUR BOX"...
> 
> But IIRC, that was without my patch?

Oh yes, your patch had nothing to do with it.

It was a more general, "do we want to allow multithreaded probing at
all" type question.  Some suggested that we allow it only by letting the
individual busses handle it (like we prototyped in the USB core),
instead of having the driver core do it.

> Wouldn't per-subsystem multithreaded probing just expose bugs that
> could also be exposed on SMP systems?

Yes, it would be the same.

> > And I'm still questioning if we should add your patch at all, as I don't
> > think any other subsystems need it.  Do you?
> 
> The css/ccw busses may profit from it, since we tend to have thousands
> of devices there. OTOH, we've already tried to make probing as
> asynchronous as possible, so maybe there isn't that much gain. I'd need
> to do some measurements (when I find some time...)

Ok, I'll keep the patch then and send it to Linus for 2.6.22, I didn't
realize your stuff would work well with it.

thanks,

greg k-h