| 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
| ||
|
Date: Thu, 22 Nov 2012 01:13:08 +0100
From: "Rafael J. Wysocki" <rjw@...k.pl>
To: Toshi Kani <toshi.kani@...com>
Cc: linux-acpi@...r.kernel.org, lenb@...nel.org,
linux-kernel@...r.kernel.org, joe@...ches.com, bhelgaas@...gle.com,
isimatu.yasuaki@...fujitsu.com, vijaymohan.pandarathil@...com
Subject: Re: [PATCH v7-1 1/5] ACPI: Add acpi_handle_<level>() interfaces
On Tuesday, November 20, 2012 06:36:28 PM Toshi Kani wrote:
> This patch introduces acpi_handle_<level>(), where <level> is
> a kernel message level such as err/warn/info, to support improved
> logging messages for ACPI, esp. hot-plug operations.
> acpi_handle_<level>() appends "ACPI" prefix and ACPI object path
> to the messages. This improves diagnosis of hotplug operations
> since an error message in a log file identifies an object that
> caused an issue. This interface acquires the global namespace
> mutex to obtain an object path. In interrupt context, it shows
> the object path as <n/a>.
>
> acpi_handle_<level>() takes acpi_handle as an argument, which is
> passed to ACPI hotplug notify handlers from the ACPICA. Therefore,
> it is always available unlike other kernel objects, such as device.
>
> For example:
> acpi_handle_err(handle, "Device don't exist, dropping EJECT\n");
> logs an error message like this at KERN_ERR.
> ACPI: \_SB_.SCK4.CPU4: Device don't exist, dropping EJECT
>
> ACPI hot-plug drivers can use acpi_handle_<level>() when they need
> to identify a target ACPI object path in their messages, such as
> error cases. The usage model is similar to dev_<level>().
> acpi_handle_<level>() can be used when a device is not created or
> is invalid during hot-plug operations. ACPI object path is also
> consistent on the platform, unlike device name that gets incremented
> over hotplug operations.
>
> ACPI drivers should use dev_<level>() when a device object is valid.
> Device name provides more user friendly information, and avoids
> acquiring the global ACPI namespace mutex. ACPI drivers also
> continue to use pr_<level>() when they do not need to specify device
> information, such as boot-up messages.
>
> Note: ACPI_[WARNING|INFO|ERROR]() are intended for the ACPICA and
> are not associated with the kernel message level.
>
> Signed-off-by: Toshi Kani <toshi.kani@...com>
> Tested-by: Vijay Mohan Pandarathil <vijaymohan.pandarathil@...com>
> ---
>
> Hi Rafael,
> This patch replaces the [PATCH v7 1/5] below in the v7 series.
> https://lkml.org/lkml/2012/11/20/719
I've applied the entire v7 series to linux-pm.git/linux-next as v3.8 material.
As far as the .sys_notify series is concerned, I don't really like it.
I'll send you my comments in the next few days.
Thanks,
Rafael
> ---
> drivers/acpi/utils.c | 38 ++++++++++++++++++++++++++++++++++++++
> include/linux/acpi.h | 43 +++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 81 insertions(+)
>
> diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c
> index 462f7e3..74437130 100644
> --- a/drivers/acpi/utils.c
> +++ b/drivers/acpi/utils.c
> @@ -28,6 +28,8 @@
> #include <linux/slab.h>
> #include <linux/init.h>
> #include <linux/types.h>
> +#include <linux/hardirq.h>
> +#include <linux/acpi.h>
> #include <acpi/acpi_bus.h>
> #include <acpi/acpi_drivers.h>
>
> @@ -457,3 +459,39 @@ acpi_evaluate_hotplug_ost(acpi_handle handle, u32 source_event,
> #endif
> }
> EXPORT_SYMBOL(acpi_evaluate_hotplug_ost);
> +
> +/**
> + * acpi_handle_printk: Print message with ACPI prefix and object path
> + *
> + * This function is called through acpi_handle_<level> macros and prints
> + * a message with ACPI prefix and object path. This function acquires
> + * the global namespace mutex to obtain an object path. In interrupt
> + * context, it shows the object path as <n/a>.
> + */
> +void
> +acpi_handle_printk(const char *level, acpi_handle handle, const char *fmt, ...)
> +{
> + struct va_format vaf;
> + va_list args;
> + struct acpi_buffer buffer = {
> + .length = ACPI_ALLOCATE_BUFFER,
> + .pointer = NULL
> + };
> + const char *path;
> +
> + va_start(args, fmt);
> + vaf.fmt = fmt;
> + vaf.va = &args;
> +
> + if (in_interrupt() ||
> + acpi_get_name(handle, ACPI_FULL_PATHNAME, &buffer) != AE_OK)
> + path = "<n/a>";
> + else
> + path = buffer.pointer;
> +
> + printk("%sACPI: %s: %pV", level, path, &vaf);
> +
> + va_end(args);
> + kfree(buffer.pointer);
> +}
> +EXPORT_SYMBOL(acpi_handle_printk);
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 0bb2070..417c96c 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -517,4 +517,47 @@ static inline int acpi_dev_pm_attach(struct device *dev) { return -ENODEV; }
> static inline void acpi_dev_pm_detach(struct device *dev) {}
> #endif
>
> +#ifdef CONFIG_ACPI
> +__printf(3, 4)
> +void acpi_handle_printk(const char *level, acpi_handle handle,
> + const char *fmt, ...);
> +#else /* !CONFIG_ACPI */
> +static inline __printf(3, 4) void
> +acpi_handle_printk(const char *level, void *handle, const char *fmt, ...) {}
> +#endif /* !CONFIG_ACPI */
> +
> +/*
> + * acpi_handle_<level>: Print message with ACPI prefix and object path
> + *
> + * These interfaces acquire the global namespace mutex to obtain an object
> + * path. In interrupt context, it shows the object path as <n/a>.
> + */
> +#define acpi_handle_emerg(handle, fmt, ...) \
> + acpi_handle_printk(KERN_EMERG, handle, fmt, ##__VA_ARGS__)
> +#define acpi_handle_alert(handle, fmt, ...) \
> + acpi_handle_printk(KERN_ALERT, handle, fmt, ##__VA_ARGS__)
> +#define acpi_handle_crit(handle, fmt, ...) \
> + acpi_handle_printk(KERN_CRIT, handle, fmt, ##__VA_ARGS__)
> +#define acpi_handle_err(handle, fmt, ...) \
> + acpi_handle_printk(KERN_ERR, handle, fmt, ##__VA_ARGS__)
> +#define acpi_handle_warn(handle, fmt, ...) \
> + acpi_handle_printk(KERN_WARNING, handle, fmt, ##__VA_ARGS__)
> +#define acpi_handle_notice(handle, fmt, ...) \
> + acpi_handle_printk(KERN_NOTICE, handle, fmt, ##__VA_ARGS__)
> +#define acpi_handle_info(handle, fmt, ...) \
> + acpi_handle_printk(KERN_INFO, handle, fmt, ##__VA_ARGS__)
> +
> +/* REVISIT: Support CONFIG_DYNAMIC_DEBUG when necessary */
> +#if defined(DEBUG) || defined(CONFIG_DYNAMIC_DEBUG)
> +#define acpi_handle_debug(handle, fmt, ...) \
> + acpi_handle_printk(KERN_DEBUG, handle, fmt, ##__VA_ARGS__)
> +#else
> +#define acpi_handle_debug(handle, fmt, ...) \
> +({ \
> + if (0) \
> + acpi_handle_printk(KERN_DEBUG, handle, fmt, ##__VA_ARGS__); \
> + 0; \
> +})
> +#endif
> +
> #endif /*_LINUX_ACPI_H*/
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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