linux-kernel - Re: [PATCH] revert "PCI: log vendor/device ID always"

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1349450831.2008.71.camel@joe-AO722>
Date:	Fri, 05 Oct 2012 08:27:11 -0700
From:	Joe Perches <joe@...ches.com>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
Cc:	Nathan Zimmer <nzimmer@....com>, linux-kernel@...r.kernel.org,
	linux-pci@...r.kernel.org, Jesse Barnes <jbarnes@...tuousgeek.org>
Subject: Re: [PATCH] revert "PCI: log vendor/device ID always"

On Fri, 2012-10-05 at 09:16 -0600, Bjorn Helgaas wrote:
> On Fri, Oct 5, 2012 at 8:54 AM, Nathan Zimmer <nzimmer@....com> wrote:
> > On 10/05/2012 09:14 AM, Joe Perches wrote:
> >> On Fri, 2012-10-05 at 08:55 -0500, Nathan Zimmer wrote:
> >>> On 10/04/2012 11:37 AM, Joe Perches wrote:
> >>>> On Thu, 2012-10-04 at 11:02 -0500, Nathan Zimmer wrote:
> >>>>> At many of our customer sites the log level is set to KERN_DEBUG. It
> >>>>> helps avoid reboots due to operator impatience.  Machines this large
> >>>>> take significantly longer then typical to boot and seeing the extra
> >>>>> messages reassures them that the kernel isn't hung.
> >>>>
> >>>> That argues for adding some KERN_INFO "still booting" messages
> >>>> not logging unnecessary KERN_DEBUG messages.
> >>>>
> >>> Actually I would think that argues for reducing boot times on these
> >>> large systems.
> >>
> >> Right.
> >>
> >> That's an independent argument, but sure, go ahead
> >> and do that too.
[]
> > Here is output for my workstation a simple 4x box
> >
> > -bash-4.1$ dmesg | grep "type [0-9][0-9] class" | wc
> >      12     108     804
> > -bash-4.1$ dmesg | wc
> >     744    6359   49474
> > Here is some output from one of the biggest boxes.
> > -bash-4.1$ dmesg | wc
> >   26503  235414 1811651
> > -bash-4.1$ dmesg | grep "type [0-9][0-9] class" | wc
> >   12085 108765  821780
> 
> Many vendors don't expose host bridges that lead to the CPU-related
> PCI devices because they don't want the OS to muck with them.  We
> currently blindly probe for these in domain 0, so we find them anyway
> (I think we should change this behavior).
> 
> I'd guess that having all these CPU-related devices around also really
> clutters up "lspci" output, and of course, consumes memory for all the
> pci_dev structs in the kernel.  It takes some time to enumerate them
> all, so avoiding that would speed up boot somewhat.
> 
> So I wonder if it might be more useful to figure out how to avoid
> enumerating those devices in the first place?  The first step would be
> to stop exposing PNP0A03/PNP0A08 host bridges that lead to them.  As I
> mentioned, we currently will probably find them anyway via blind
> probing.  You might be able to avoid that if you could place them in a
> PCI domain other than 0

And in the meantime, maybe something like this and not logging
at KERN_DEBUG when using verbose_boot would help avoid impatient
operator reboots.

 drivers/pci/hotplug/sgi_hotplug.c |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/pci/hotplug/sgi_hotplug.c b/drivers/pci/hotplug/sgi_hotplug.c
index f64ca92..b3abd1a 100644
--- a/drivers/pci/hotplug/sgi_hotplug.c
+++ b/drivers/pci/hotplug/sgi_hotplug.c
@@ -368,6 +368,10 @@ static int enable_slot(struct hotplug_slot *bss_hotplug_slot)
 		}
 	}
 
+	if (some_verbose_boot_flag)
+		dev_info(&slot->pci_bus->self->dev, "Testing slot %d\n",
+			 slot->device_num + 1);
+
 	num_funcs = pci_scan_slot(slot->pci_bus,
 				  PCI_DEVFN(slot->device_num + 1, 0));
 	if (!num_funcs) {



--
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/