lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 6 Apr 2007 17:43:03 -0700
From:	Greg KH <gregkh@...e.de>
To:	Cornelia Huck <cornelia.huck@...ibm.com>
Cc:	Greg KH <greg@...ah.com>, Adrian Bunk <bunk@...sta.de>,
	linux-pci@...ey.karlin.mff.cuni.cz, linux-kernel@...r.kernel.org
Subject: Re: [2.6 patch] remove the broken PCI_MULTITHREAD_PROBE option

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@...ah.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
-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ