| 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
| ||
|
Message-ID: <4AE5E72E.1020702@sgi.com>
Date: Mon, 26 Oct 2009 11:15:10 -0700
From: Mike Travis <travis@....com>
To: Bjorn Helgaas <bjorn.helgaas@...com>
CC: Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Jack Steiner <steiner@....com>,
Zhang Rui <rui.zhang@...el.com>, Len Brown <lenb@...nel.org>,
Thomas Renninger <trenn@...e.de>,
Alexey Dobriyan <adobriyan@...il.com>,
Myron Stowe <myron.stowe@...com>,
Feng Tang <feng.tang@...el.com>,
Suresh Siddha <suresh.b.siddha@...el.com>,
Yinghai Lu <yhlu.kernel@...il.com>, linux-acpi@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/8] SGI x86_64 UV: Limit the number of ACPI messages
Bjorn Helgaas wrote:
> On Fri, 2009-10-23 at 18:37 -0500, Mike Travis wrote:
>> plain text document attachment (limit_acpi)
>> Limit number of ACPI messages of the form:
>>
>> [ 0.000000] ACPI: LSAPIC (acpi_id[0x00] lsapic_id[0x00] lsapic_eid[0x00] enabled)
>>
>> [ 99.638655] processor ACPI0007:00: registered as cooling_device0
>>
>> Cc: Zhang Rui <rui.zhang@...el.com>
>> Cc: Len Brown <lenb@...nel.org>
>> Cc: Thomas Renninger <trenn@...e.de>
>> Cc: Bjorn Helgaas <bjorn.helgaas@...com>
>> Cc: Alexey Dobriyan <adobriyan@...il.com>
>> Cc: Myron Stowe <myron.stowe@...com>
>> Cc: Feng Tang <feng.tang@...el.com>
>> Cc: Suresh Siddha <suresh.b.siddha@...el.com>
>> Cc: Yinghai Lu <yhlu.kernel@...il.com>
>> Cc: linux-acpi@...r.kernel.org
>> Cc: linux-kernel@...r.kernel.org
>> Signed-off-by: Mike Travis <travis@....com>
>> ---
>> drivers/acpi/fan.c | 7 ++++++-
>> drivers/acpi/processor_core.c | 8 ++++++--
>> drivers/acpi/tables.c | 15 ++++++++++-----
>> 3 files changed, 22 insertions(+), 8 deletions(-)
>>
>> --- linux.orig/drivers/acpi/fan.c
>> +++ linux/drivers/acpi/fan.c
>> @@ -243,6 +243,7 @@
>> int result = 0;
>> int state = 0;
>> struct thermal_cooling_device *cdev;
>> + static int msgcnt;
>>
>> if (!device)
>> return -EINVAL;
>> @@ -267,7 +268,11 @@
>> goto end;
>> }
>>
>> - dev_info(&device->dev, "registered as cooling_device%d\n", cdev->id);
>> + if (msgcnt < 4 || !limit_console_output(false)) {
>> + dev_info(&device->dev,
>> + "registered as cooling_device%d\n", cdev->id);
>> + msgcnt++;
>> + }
>
> I'm personally not in favor of printing some, but not all, of these
> messages. That leads to questions when analyzing a dmesg log, such as
> "Hmm, I see I have 64 CPUs, but only 0-3 are registered as cooling
> devices. Does that mean something is wrong?"
>
> But I would be glad to see this particular message removed completely.
I didn't want to make the decision to remove messages as the original
authors might have very good reasons for including them.
Note that the dmesg log (kernel log buffer) still does have every one of
the messages, only the prints to the console output (which usually is a
serial connection [or IPMI] on servers) are limited.
>
>> device->driver_data = cdev;
>> result = sysfs_create_link(&device->dev.kobj,
>> --- linux.orig/drivers/acpi/processor_core.c
>> +++ linux/drivers/acpi/processor_core.c
>> @@ -775,6 +775,7 @@
>> struct acpi_processor *pr = NULL;
>> int result = 0;
>> struct sys_device *sysdev;
>> + static int msgcnt;
>>
>> pr = kzalloc(sizeof(struct acpi_processor), GFP_KERNEL);
>> if (!pr)
>> @@ -845,8 +846,11 @@
>> goto err_power_exit;
>> }
>>
>> - dev_info(&device->dev, "registered as cooling_device%d\n",
>> - pr->cdev->id);
>> + if (msgcnt < 4 || !limit_console_output(false)) {
>> + dev_info(&device->dev, "registered as cooling_device%d\n",
>> + pr->cdev->id);
>> + msgcnt++;
>> + }
>>
>> result = sysfs_create_link(&device->dev.kobj,
>> &pr->cdev->device.kobj,
>> --- linux.orig/drivers/acpi/tables.c
>> +++ linux/drivers/acpi/tables.c
>> @@ -170,11 +170,16 @@
>> case ACPI_MADT_TYPE_LOCAL_SAPIC:
>> {
>> struct acpi_madt_local_sapic *p =
>> - (struct acpi_madt_local_sapic *)header;
>> - printk(KERN_INFO PREFIX
>> - "LSAPIC (acpi_id[0x%02x] lsapic_id[0x%02x] lsapic_eid[0x%02x] %s)\n",
>> - p->processor_id, p->id, p->eid,
>> - (p->lapic_flags & ACPI_MADT_ENABLED) ? "enabled" : "disabled");
>> + (struct acpi_madt_local_sapic *)header;
>> +
>> + if (p->eid < 8 || !limit_console_output(false))
>> + printk(KERN_INFO PREFIX
>> + "LSAPIC (acpi_id[0x%02x] "
>> + "lsapic_id[0x%02x] "
>> + "lsapic_eid[0x%02x] %s)\n",
>> + p->processor_id, p->id, p->eid,
>> + (p->lapic_flags & ACPI_MADT_ENABLED) ?
>> + "enabled" : "disabled");
>
> I know we print way too much stuff for every processor, but again, I'd
> rather see all CPUs or none. I think there's a little more value in
> this one than the cooling device one (probably because I do a lot of
> platform bringup), but it could certainly be made KERN_DEBUG and/or
> combined with another processor discovery line.
This was the major reason why I left the default as it currently is, and
made it a startup option that a site can choose to use or not.
The intent of printing a few messages was to give context to the last line
in this sequence:
[ 99.638655] processor ACPI0007:00: registered as cooling_device0
[ 99.648277] processor ACPI0007:01: registered as cooling_device1
[ 99.657976] processor ACPI0007:02: registered as cooling_device2
[ 99.667229] processor ACPI0007:03: registered as cooling_device3
[ 99.676517] printk: further related messages suppressed
Thanks,
Mike
>
> Bjorn
>
>> }
>> break;
>>
>>
--
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