From 40599072dca3ec7d4c9ff8271978be169f974638 Mon Sep 17 00:00:00 2001 From: Pavel Machek Date: Tue, 25 Nov 2008 12:05:08 +0100 Subject: ACPI: scheduling in atomic via acpi_evaluate_integer () Now I know why I had strange "scheduling in atomic" problems: acpi_evaluate_integer() does malloc(..., irqs_disabled() ? GFP_ATOMIC : GFP_KERNEL)... which is (of course) broken. There's no way to reliably tell if we need GFP_ATOMIC or not from code, this one for example fails to detect spinlocks held. Fortunately, allocation seems small enough to be done on stack. Signed-off-by: Pavel Machek Acked-by: Bob Moore Signed-off-by: Len Brown --- drivers/acpi/utils.c | 16 ++++------------ 1 file changed, 4 insertions(+), 12 deletions(-) (limited to 'drivers/acpi') diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c index e827be36ee8..f844941089b 100644 --- a/drivers/acpi/utils.c +++ b/drivers/acpi/utils.c @@ -259,34 +259,26 @@ acpi_evaluate_integer(acpi_handle handle, struct acpi_object_list *arguments, unsigned long long *data) { acpi_status status = AE_OK; - union acpi_object *element; + union acpi_object element; struct acpi_buffer buffer = { 0, NULL }; - if (!data) return AE_BAD_PARAMETER; - element = kzalloc(sizeof(union acpi_object), irqs_disabled() ? GFP_ATOMIC: GFP_KERNEL); - if (!element) - return AE_NO_MEMORY; - buffer.length = sizeof(union acpi_object); - buffer.pointer = element; + buffer.pointer = &element; status = acpi_evaluate_object(handle, pathname, arguments, &buffer); if (ACPI_FAILURE(status)) { acpi_util_eval_error(handle, pathname, status); - kfree(element); return status; } - if (element->type != ACPI_TYPE_INTEGER) { + if (element.type != ACPI_TYPE_INTEGER) { acpi_util_eval_error(handle, pathname, AE_BAD_DATA); - kfree(element); return AE_BAD_DATA; } - *data = element->integer.value; - kfree(element); + *data = element.integer.value; ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Return value [%llu]\n", *data)); -- cgit v1.2.3-70-g09d2