On Sat, 22 Jul 2006, Brown, Len wrote:
> > drivers/acpi/pci_link.c::acpi_pci_link_set() sets the GFP_ATOMIC for
> > kmalloc() allocation for no first-sight obvious reason; as far as I
> > can see this is always called outside the atomic/interrupt context, so
> > GFP_KERNEL allocation should be used instead.
> this would oops on a resume from suspend -- when it is called with
> interrupts off.
But in such a case I guess the following callchain has a problem:
acpi_pci_link_resume -> acpi_pci_link_set -> acpi_set_current_resources ->
acpi_rs_set_srs_method_data -> acpi_ut_create_internal_object_dbg ->
acpi_ut_allocate_object_desc_dbg -> acpi_os_acquire_object ->
kmem_cache_alloc with GFP_KERNEL flag.
What about the following patch to handle both cases without oopsing? (I am
not using the acpi_in_resume flag, as it is makred for removal)
Signed-off-by: Jiri Kosina <[email protected]>
--- drivers/acpi/osl.c.orig 2006-07-15 21:00:43.000000000 +0200
+++ drivers/acpi/osl.c 2006-07-23 16:03:08.000000000 +0200
@@ -1141,7 +1141,13 @@ acpi_status acpi_os_release_object(acpi_
void *acpi_os_acquire_object(acpi_cache_t * cache)
{
- void *object = kmem_cache_alloc(cache, GFP_KERNEL);
+ void *object;
+
+ /* irqs could be disabled when resuming from suspend */
+ if (irqs_disabled())
+ object = kmem_cache_alloc(cache, GFP_ATOMIC);
+ else
+ object = kmem_cache_alloc(cache, GFP_KERNEL);
WARN_ON(!object);
return object;
}
--- drivers/acpi/pci_link.c.orig 2006-07-15 21:00:43.000000000 +0200
+++ drivers/acpi/pci_link.c 2006-07-23 16:01:42.000000000 +0200
@@ -318,7 +318,12 @@ static int acpi_pci_link_set(struct acpi
if (!link || !irq)
return_VALUE(-EINVAL);
- resource = kmalloc(sizeof(*resource) + 1, GFP_ATOMIC);
+ /* irqs could be disabled when resuming from suspend */
+ if (irqs_disabled())
+ resource = kmalloc(sizeof(*resource) + 1, GFP_ATOMIC);
+ else
+ resource = kmalloc(sizeof(*resource) + 1, GFP_KERNEL);
+
if (!resource)
return_VALUE(-ENOMEM);
--
JiKos.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
