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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <506DB30F.2000704@sgi.com>
Date:	Thu, 4 Oct 2012 11:02:23 -0500
From:	Nathan Zimmer <nzimmer@....com>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
CC:	<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 10/03/2012 05:54 PM, Bjorn Helgaas wrote:
> On Tue, Oct 2, 2012 at 8:23 AM, Nathan Zimmer <nzimmer@....com> wrote:
>> Revert commit id 2c6413aee215a43b1f95e218067abcde50ccbc5e
>> On larger systems (256 cores+) with signifigant IO attached this single message
>> represents over 20% of the messages at boot.
> Is this causing a problem?  The messages are at KERN_DEBUG, so they
> shouldn't be going to the console by default anyway.

The problems is that it really does tend to overwhelm dmesg on large 
systems.
This causes two issues, one is it makes it harder to notice unexpected 
messages, second it tends to push out more other messages.

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.

> I/O devices normally have at least one BAR, as well as some PME
> messages, so a change like this won't affect them too much.  My guess
> is that it's really the large number of CPUs, where we find all the
> uncore/memory controller/etc stuff where this is a problem.  Those
> devices don't have BARs, so
> this line is probably the only information about them in dmesg.
It certainly appears that this is the only line about them in dmesg.

>> Cc: Bjorn Helgaas <bhelgaas@...gle.com>
>> Cc: Jesse Barnes <jbarnes@...tuousgeek.org>
>>
>> Signed-off-by: Nathan Zimmer <nzimmer@....com>
>> ---
>>   drivers/pci/probe.c |    4 ++--
>>   1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
>> index 9f8a6b7..a1add54 100644
>> --- a/drivers/pci/probe.c
>> +++ b/drivers/pci/probe.c
>> @@ -1002,8 +1002,8 @@ int pci_setup_device(struct pci_dev *dev)
>>          dev->revision = class & 0xff;
>>          dev->class = class >> 8;                    /* upper 3 bytes */
>>
>> -       dev_printk(KERN_DEBUG, &dev->dev, "[%04x:%04x] type %02x class %#08x\n",
>> -                  dev->vendor, dev->device, dev->hdr_type, dev->class);
>> +       dev_dbg(&dev->dev, "[%04x:%04x] type %02x class %#08x\n",
>> +               dev->vendor, dev->device, dev->hdr_type, dev->class);
>>
>>          /* need to have dev->class ready */
>>          dev->cfg_size = pci_cfg_space_size(dev);
>> --
>> 1.6.0.2
>>

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