[BUG] sleeping function called from invalid context during resume

[BUG] sleeping function called from invalid context during resume

[john stultz]

I got the following on my laptop w/ 2.6.18-rc1.

thanks
-john

Stopping tasks:
================================================================
=======================|
pnp: Device 00:0b disabled.
ACPI: PCI interrupt for device 0000:02:01.0 disabled
ACPI: PCI interrupt for device 0000:00:1f.5 disabled
ACPI: PCI interrupt for device 0000:00:1d.7 disabled
ACPI: PCI interrupt for device 0000:00:1d.2 disabled
ACPI: PCI interrupt for device 0000:00:1d.1 disabled
ACPI: PCI interrupt for device 0000:00:1d.0 disabled
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Back to C!
BUG: sleeping function called from invalid context at mm/slab.c:2882
in_atomic():0, irqs_disabled():1
 [<c0103d59>] show_trace_log_lvl+0x149/0x170
 [<c01052ab>] show_trace+0x1b/0x20
 [<c01052d4>] dump_stack+0x24/0x30
 [<c0116e51>] __might_sleep+0xa1/0xc0
 [<c0165cb5>] kmem_cache_zalloc+0xa5/0xc0
 [<c0264b5a>] acpi_os_acquire_object+0x11/0x41
 [<c027a898>] acpi_ut_allocate_object_desc_dbg+0xf/0x45
 [<c027a926>] acpi_ut_create_internal_object_dbg+0x16/0x69
 [<c0276bd3>] acpi_rs_set_srs_method_data+0x80/0xdd
 [<c02762e5>] acpi_set_current_resources+0x31/0x3f
 [<c02826bf>] acpi_pci_link_set+0xfc/0x1a5
 [<c0282a25>] irqrouter_resume+0x52/0x73
 [<c02b92aa>] __sysdev_resume+0x1a/0x90
 [<c02b9367>] sysdev_resume+0x47/0x70
 [<c02bf1f8>] device_power_up+0x8/0x10
 [<c0142185>] suspend_enter+0x65/0x80
 [<c01422a8>] enter_state+0xc8/0x1b0
 [<c014242f>] state_store+0x9f/0xb0
 [<c01a502e>] subsys_attr_store+0x2e/0x30
 [<c01a5828>] sysfs_write_file+0xb8/0x100
 [<c0169187>] vfs_write+0xa7/0x190
 [<c0169bc7>] sys_write+0x47/0x70
 [<c01031fd>] sysenter_past_esp+0x56/0x8d
 [<b7fd3410>] 0xb7fd3410
PM: Writing back config space on device 0000:00:01.0 at offset 7 (was
2a03030, w
riting 22a03030)
PCI: Enabling device 0000:00:1d.0 (0000 -> 0001)
ACPI: PCI Interrupt 0000:00:1d.0[A] -> Link [LNKA] -> GSI 11 (level,
low) -> IRQ
 11
PCI: Setting latency timer of device 0000:00:1d.0 to 64
PM: Writing back config space on device 0000:00:1d.0 at offset f (was
100, writi
ng 10b)

RE: [BUG] sleeping function called from invalid context during resume

[Brown, Len]

>I got the following on my laptop w/ 2.6.18-rc1.
>
>thanks
>-john
>
>Stopping tasks:
>================================================================
>=======================|
>pnp: Device 00:0b disabled.
>ACPI: PCI interrupt for device 0000:02:01.0 disabled
>ACPI: PCI interrupt for device 0000:00:1f.5 disabled
>ACPI: PCI interrupt for device 0000:00:1d.7 disabled
>ACPI: PCI interrupt for device 0000:00:1d.2 disabled
>ACPI: PCI interrupt for device 0000:00:1d.1 disabled
>ACPI: PCI interrupt for device 0000:00:1d.0 disabled
>Intel machine check architecture supported.
>Intel machine check reporting enabled on CPU#0.
>Back to C!
>BUG: sleeping function called from invalid context at mm/slab.c:2882
>in_atomic():0, irqs_disabled():1
> [<c0103d59>] show_trace_log_lvl+0x149/0x170
> [<c01052ab>] show_trace+0x1b/0x20
> [<c01052d4>] dump_stack+0x24/0x30
> [<c0116e51>] __might_sleep+0xa1/0xc0
> [<c0165cb5>] kmem_cache_zalloc+0xa5/0xc0
> [<c0264b5a>] acpi_os_acquire_object+0x11/0x41

yep, the new slab for objects makes this path immune to
the acpi_in_resume hack in acpi_os_allocate()

I think we need to get rid of the acpi_in_resume hack
and use system_state != SYSTEM_RUNNING to address this.

-Len

> [<c027a898>] acpi_ut_allocate_object_desc_dbg+0xf/0x45
> [<c027a926>] acpi_ut_create_internal_object_dbg+0x16/0x69
> [<c0276bd3>] acpi_rs_set_srs_method_data+0x80/0xdd
> [<c02762e5>] acpi_set_current_resources+0x31/0x3f
> [<c02826bf>] acpi_pci_link_set+0xfc/0x1a5
> [<c0282a25>] irqrouter_resume+0x52/0x73
> [<c02b92aa>] __sysdev_resume+0x1a/0x90
> [<c02b9367>] sysdev_resume+0x47/0x70
> [<c02bf1f8>] device_power_up+0x8/0x10
> [<c0142185>] suspend_enter+0x65/0x80
> [<c01422a8>] enter_state+0xc8/0x1b0
> [<c014242f>] state_store+0x9f/0xb0
> [<c01a502e>] subsys_attr_store+0x2e/0x30
> [<c01a5828>] sysfs_write_file+0xb8/0x100
> [<c0169187>] vfs_write+0xa7/0x190
> [<c0169bc7>] sys_write+0x47/0x70
> [<c01031fd>] sysenter_past_esp+0x56/0x8d
> [<b7fd3410>] 0xb7fd3410
>PM: Writing back config space on device 0000:00:01.0 at offset 7 (was
>2a03030, w
>riting 22a03030)
>PCI: Enabling device 0000:00:1d.0 (0000 -> 0001)
>ACPI: PCI Interrupt 0000:00:1d.0[A] -> Link [LNKA] -> GSI 11 (level,
>low) -> IRQ
> 11
>PCI: Setting latency timer of device 0000:00:1d.0 to 64
>PM: Writing back config space on device 0000:00:1d.0 at offset f (was
>100, writi
>ng 10b)
>

Re: [BUG] sleeping function called from invalid context during resume

[Parag Warudkar]

john stultz <johnstul <at> us.ibm.com> writes:

> 
> I got the following on my laptop w/ 2.6.18-rc1.
> 
> thanks
> -john
 
> Back to C!
> BUG: sleeping function called from invalid context at mm/slab.c:2882
> in_atomic():0, irqs_disabled():1
>  [<c0103d59>] show_trace_log_lvl+0x149/0x170
>  [<c01052ab>] show_trace+0x1b/0x20
>  [<c01052d4>] dump_stack+0x24/0x30
>  [<c0116e51>] __might_sleep+0xa1/0xc0
>  [<c0165cb5>] kmem_cache_zalloc+0xa5/0xc0
>  [<c0264b5a>] acpi_os_acquire_object+0x11/0x41
>  [<c027a898>] acpi_ut_allocate_object_desc_dbg+0xf/0x45
>  [<c027a926>] acpi_ut_create_internal_object_dbg+0x16/0x69
>  [<c0276bd3>] acpi_rs_set_srs_method_data+0x80/0xdd
>  [<c02762e5>] acpi_set_current_resources+0x31/0x3f
>  [<c02826bf>] acpi_pci_link_set+0xfc/0x1a5
>  [<c0282a25>] irqrouter_resume+0x52/0x73
>  [<c02b92aa>] __sysdev_resume+0x1a/0x90
>  [<c02b9367>] sysdev_resume+0x47/0x70
>  [<c02bf1f8>] device_power_up+0x8/0x10
>  [<c0142185>] suspend_enter+0x65/0x80

Hmm.. This was fixed in -mm back in February
(http://www.ussg.iu.edu/hypermail/linux/kernel/0602.1/2022.html). 
Not sure why it hasn't flowed in to mainline. Does this patch below (against 
2.6.18-rc1) fix it?

Parag

Signed-off-by: Parag Warudkar <kernel-stuff@comcast.net>

--- linux-2.6.17/drivers/acpi/osl.c.orig        2006-07-06 
23:22:03.000000000 -0400
+++ linux-2.6.17/drivers/acpi/osl.c     2006-07-06 23:29:43.000000000 -0400
@@ -1130,7 +1130,11 @@ acpi_status acpi_os_release_object(acpi_

 void *acpi_os_acquire_object(acpi_cache_t * cache)
 {
-       void *object = kmem_cache_zalloc(cache, GFP_KERNEL);
+       void* object;
+       if (acpi_in_resume)
+               object = kmem_cache_zalloc(cache, GFP_ATOMIC);
+       else
+               object = kmem_cache_zalloc(cache, GFP_KERNEL);
        WARN_ON(!object);
        return object;
 }

Re: [BUG] sleeping function called from invalid context during resume

[Andrew Morton]

On Thu, 6 Jul 2006 23:10:08 -0400
"Brown, Len" <len.brown@intel.com> wrote:

> 
> >I got the following on my laptop w/ 2.6.18-rc1.
> >
> >thanks
> >-john
> >
> >Stopping tasks:
> >================================================================
> >=======================|
> >pnp: Device 00:0b disabled.
> >ACPI: PCI interrupt for device 0000:02:01.0 disabled
> >ACPI: PCI interrupt for device 0000:00:1f.5 disabled
> >ACPI: PCI interrupt for device 0000:00:1d.7 disabled
> >ACPI: PCI interrupt for device 0000:00:1d.2 disabled
> >ACPI: PCI interrupt for device 0000:00:1d.1 disabled
> >ACPI: PCI interrupt for device 0000:00:1d.0 disabled
> >Intel machine check architecture supported.
> >Intel machine check reporting enabled on CPU#0.
> >Back to C!
> >BUG: sleeping function called from invalid context at mm/slab.c:2882
> >in_atomic():0, irqs_disabled():1
> > [<c0103d59>] show_trace_log_lvl+0x149/0x170
> > [<c01052ab>] show_trace+0x1b/0x20
> > [<c01052d4>] dump_stack+0x24/0x30
> > [<c0116e51>] __might_sleep+0xa1/0xc0
> > [<c0165cb5>] kmem_cache_zalloc+0xa5/0xc0
> > [<c0264b5a>] acpi_os_acquire_object+0x11/0x41
> 
> yep, the new slab for objects makes this path immune to
> the acpi_in_resume hack in acpi_os_allocate()

hm.  Linus's new suspend/resume thing seems to have a two-phase suspend,
but not, afaict, a two-phase resume.  If it did, and if the second resume
phase were to run with IRQs enabled then we should be able to address this
appropriately.

> I think we need to get rid of the acpi_in_resume hack
> and use system_state != SYSTEM_RUNNING to address this.

Well if hacks are OK it'd actually be reliable to do

	/* comment goes here */
	kmalloc(size, irqs_disabled() ? GFP_ATOMIC : GFP_KERNEL);

because the irqs_disabled() thing happens for well-defined reasons. 
Certainly that's better than looking at system_state (and I don't think we
leave SYSTEM_RUNNING during suspend/resume anyway).

RE: [BUG] sleeping function called from invalid context during resume

[Brown, Len]

 
>> >I got the following on my laptop w/ 2.6.18-rc1.
>> >
>> >thanks
>> >-john
>> >
>> >Stopping tasks:
>> >================================================================
>> >=======================|
>> >pnp: Device 00:0b disabled.
>> >ACPI: PCI interrupt for device 0000:02:01.0 disabled
>> >ACPI: PCI interrupt for device 0000:00:1f.5 disabled
>> >ACPI: PCI interrupt for device 0000:00:1d.7 disabled
>> >ACPI: PCI interrupt for device 0000:00:1d.2 disabled
>> >ACPI: PCI interrupt for device 0000:00:1d.1 disabled
>> >ACPI: PCI interrupt for device 0000:00:1d.0 disabled
>> >Intel machine check architecture supported.
>> >Intel machine check reporting enabled on CPU#0.
>> >Back to C!
>> >BUG: sleeping function called from invalid context at mm/slab.c:2882
>> >in_atomic():0, irqs_disabled():1
>> > [<c0103d59>] show_trace_log_lvl+0x149/0x170
>> > [<c01052ab>] show_trace+0x1b/0x20
>> > [<c01052d4>] dump_stack+0x24/0x30
>> > [<c0116e51>] __might_sleep+0xa1/0xc0
>> > [<c0165cb5>] kmem_cache_zalloc+0xa5/0xc0
>> > [<c0264b5a>] acpi_os_acquire_object+0x11/0x41
>> 
>> yep, the new slab for objects makes this path immune to
>> the acpi_in_resume hack in acpi_os_allocate()
>
>hm.  Linus's new suspend/resume thing seems to have a 
>two-phase suspend,
>but not, afaict, a two-phase resume.  If it did, and if the 
>second resume
>phase were to run with IRQs enabled then we should be able to 
>address this
>appropriately.
>
>> I think we need to get rid of the acpi_in_resume hack
>> and use system_state != SYSTEM_RUNNING to address this.
>
>Well if hacks are OK it'd actually be reliable to do
>
>	/* comment goes here */
>	kmalloc(size, irqs_disabled() ? GFP_ATOMIC : GFP_KERNEL);
>
>because the irqs_disabled() thing happens for well-defined reasons. 
>Certainly that's better than looking at system_state (and I 
>don't think we
>leave SYSTEM_RUNNING during suspend/resume anyway).

If system_state != SYSTEM_RUNNING on resume, theen __might_sleep()
would not have spit out the dump_stack() above.

This is exactly like boot -- we are bringing up the system
and we need to configure interrupts, which runs AML,
which calls kmalloc in a variety of ways, all of which call
__might_sleep.

It seems simplest to have resume admit that it is like boot
and that the early allocations with interrupts off simply
must succeed or it is game-off.

-Len

Re: [BUG] sleeping function called from invalid context during resume

[Andrew Morton]

On Fri, 7 Jul 2006 12:32:41 -0400
"Brown, Len" <len.brown@intel.com> wrote:

>  
> >
> >> I think we need to get rid of the acpi_in_resume hack
> >> and use system_state != SYSTEM_RUNNING to address this.
> >
> >Well if hacks are OK it'd actually be reliable to do
> >
> >	/* comment goes here */
> >	kmalloc(size, irqs_disabled() ? GFP_ATOMIC : GFP_KERNEL);
> >
> >because the irqs_disabled() thing happens for well-defined reasons. 
> >Certainly that's better than looking at system_state (and I 
> >don't think we
> >leave SYSTEM_RUNNING during suspend/resume anyway).
> 
> If system_state != SYSTEM_RUNNING on resume, theen __might_sleep()
> would not have spit out the dump_stack() above.
> 
> This is exactly like boot -- we are bringing up the system
> and we need to configure interrupts, which runs AML,
> which calls kmalloc in a variety of ways, all of which call
> __might_sleep.
> 
> It seems simplest to have resume admit that it is like boot
> and that the early allocations with interrupts off simply
> must succeed or it is game-off.
> 

No, we shouldn't expand the use of system_state.  Code continues to be
merged which uses it.  If we also merge code which enhances its semantics
then we're getting into quadratically-increasing nastiness rather than
linearly-increasing.

Callers should tell callees what to do.  Callees shouldn't be peeking at
globals to work out what to do.

Lacking any other caller-passed indication, it would be much better for
acpi to look at irqs_disabled().  That's effectively a task-local,
cpu-local argument which was passed down to callees.  It's hacky - it's
like the PF_foo flags.  But it's heaps better than having all the kernel
fight over the state of a global.

RE: [BUG] sleeping function called from invalid context during resume

[Brown, Len]

>> >> I think we need to get rid of the acpi_in_resume hack
>> >> and use system_state != SYSTEM_RUNNING to address this.
>> >
>> >Well if hacks are OK it'd actually be reliable to do
>> >
>> >	/* comment goes here */
>> >	kmalloc(size, irqs_disabled() ? GFP_ATOMIC : GFP_KERNEL);
>> >
>> >because the irqs_disabled() thing happens for well-defined reasons. 
>> >Certainly that's better than looking at system_state (and I 
>> >don't think we
>> >leave SYSTEM_RUNNING during suspend/resume anyway).
>> 
>> If system_state != SYSTEM_RUNNING on resume, theen __might_sleep()
>> would not have spit out the dump_stack() above.
>> 
>> This is exactly like boot -- we are bringing up the system
>> and we need to configure interrupts, which runs AML,
>> which calls kmalloc in a variety of ways, all of which call
>> __might_sleep.
>> 
>> It seems simplest to have resume admit that it is like boot
>> and that the early allocations with interrupts off simply
>> must succeed or it is game-off.
>> 
>
>No, we shouldn't expand the use of system_state.  Code continues to be
>merged which uses it.  If we also merge code which enhances 
>its semantics then we're getting into quadratically-increasing
>nastiness rather than linearly-increasing.
>
>Callers should tell callees what to do.  Callees shouldn't be 
>peeking at globals to work out what to do.
>
>Lacking any other caller-passed indication, it would be much better for
>acpi to look at irqs_disabled().  That's effectively a task-local,
>cpu-local argument which was passed down to callees.  It's hacky - it's
>like the PF_foo flags.  But it's heaps better than having all 
>the kernel fight over the state of a global.

I didn't propose that kmalloc callers peek at system_state.
I proposed that system_state be set properly on resume
exactly like it is set on boot -- SYSTEM_RUNNING means
we are up with interrupts enabled.

Note that this issue is not specific to ACPI, any other code
that calls kmalloc during resume will hit __might_sleep().
This is taken care of by system_state in the case of boot
and the callers don't know anything about it -- resume
is the same case and should work the same way.

-Len

Re: [BUG] sleeping function called from invalid context during resume

[Pavel Machek]

Hi!

> >Lacking any other caller-passed indication, it would be much better for
> >acpi to look at irqs_disabled().  That's effectively a task-local,
> >cpu-local argument which was passed down to callees.  It's hacky - it's
> >like the PF_foo flags.  But it's heaps better than having all 
> >the kernel fight over the state of a global.
> 
> I didn't propose that kmalloc callers peek at system_state.
> I proposed that system_state be set properly on resume
> exactly like it is set on boot -- SYSTEM_RUNNING means
> we are up with interrupts enabled.
> 
> Note that this issue is not specific to ACPI, any other code
> that calls kmalloc during resume will hit __might_sleep().
> This is taken care of by system_state in the case of boot
> and the callers don't know anything about it -- resume
> is the same case and should work the same way.

I'd agree with Andrew here -- lets not mess with system_state. It is
broken by design, anyway.

Part of code would prefer SYSTEM_BOOTING during resume (because we are
initializing the devices), but I'm pretty sure some other piece of
code will get confused by that.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [linux-pm] [BUG] sleeping function called from invalid context during resume

[Alan Stern]

On Sat, 8 Jul 2006, Pavel Machek wrote:

> > I didn't propose that kmalloc callers peek at system_state.
> > I proposed that system_state be set properly on resume
> > exactly like it is set on boot -- SYSTEM_RUNNING means
> > we are up with interrupts enabled.
> > 
> > Note that this issue is not specific to ACPI, any other code
> > that calls kmalloc during resume will hit __might_sleep().
> > This is taken care of by system_state in the case of boot
> > and the callers don't know anything about it -- resume
> > is the same case and should work the same way.
> 
> I'd agree with Andrew here -- lets not mess with system_state. It is
> broken by design, anyway.
> 
> Part of code would prefer SYSTEM_BOOTING during resume (because we are
> initializing the devices), but I'm pretty sure some other piece of
> code will get confused by that.

Whichever way you guys decide this should go, let me know.  I'm sitting on 
a patch for ACPI (a couple of routines that make blocking calls with 
interrupts disabled) and I'd like to know what to do with it.  Should I 
just send it to Len and linux-acpi as is?

Alan Stern

RE: [BUG] sleeping function called from invalid context during resume

[Brown, Len]

Okay, if system_state is off limits, there here is what I've got
(interesting part is the last 20 lines)

ACPI: acpi_os_allocate() fixes

Replace acpi_in_resume with a more general hack
to check irqs_disabled() on any kmalloc() from ACPI.
While setting (system_state != SYSTEM_RUNNING) on resume
seemed more general, Andrew Morton preferred this approach.

http://bugzilla.kernel.org/show_bug.cgi?id=3469

Make acpi_os_allocate() into an inline function to
allow /proc/slab_allocators to work.

Delete some memset() that could fault on allocation failure.

Signed-off-by: Len Brown <len.brown@intel.com>

 drivers/acpi/osl.c               |   30 ------------------------------
 drivers/acpi/parser/psutils.c    |    2 --
 drivers/acpi/pci_link.c          |    7 -------
 drivers/acpi/utilities/utalloc.c |    2 ++
 include/acpi/acmacros.h          |    8 +++++++-
 include/acpi/platform/aclinux.h  |   21 +++++++++++++++++++++
 6 files changed, 30 insertions(+), 40 deletions(-)


diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index eedb05c..47dfde9 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -136,16 +136,6 @@ #else
 #endif
 }
 
-
-extern int acpi_in_resume;
-void *acpi_os_allocate(acpi_size size)
-{
-	if (acpi_in_resume)
-		return kmalloc(size, GFP_ATOMIC);
-	else
-		return kmalloc(size, GFP_KERNEL);
-}
-
 acpi_status acpi_os_get_root_pointer(u32 flags, struct acpi_pointer
*addr)
 {
 	if (efi_enabled) {
@@ -1115,26 +1105,6 @@ acpi_status acpi_os_release_object(acpi_
 	return (AE_OK);
 }
 
-/**********************************************************************
*********
- *
- * FUNCTION:    acpi_os_acquire_object
- *
- * PARAMETERS:  Cache           - Handle to cache object
- *              ReturnObject    - Where the object is returned
- *
- * RETURN:      Status
- *
- * DESCRIPTION: Return a zero-filled object.
- *
-
************************************************************************
******/
-
-void *acpi_os_acquire_object(acpi_cache_t * cache)
-{
-	void *object = kmem_cache_zalloc(cache, GFP_KERNEL);
-	WARN_ON(!object);
-	return object;
-}
-
 
/***********************************************************************
*******
  *
  * FUNCTION:    acpi_os_validate_interface
diff --git a/drivers/acpi/parser/psutils.c
b/drivers/acpi/parser/psutils.c
index 182474a..d405387 100644
--- a/drivers/acpi/parser/psutils.c
+++ b/drivers/acpi/parser/psutils.c
@@ -139,12 +139,10 @@ union acpi_parse_object *acpi_ps_alloc_o
 		/* The generic op (default) is by far the most common
(16 to 1) */
 
 		op = acpi_os_acquire_object(acpi_gbl_ps_node_cache);
-		memset(op, 0, sizeof(struct acpi_parse_obj_common));
 	} else {
 		/* Extended parseop */
 
 		op = acpi_os_acquire_object(acpi_gbl_ps_node_ext_cache);
-		memset(op, 0, sizeof(struct acpi_parse_obj_named));
 	}
 
 	/* Initialize the Op */
diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
index 8197c0e..7f3e7e7 100644
--- a/drivers/acpi/pci_link.c
+++ b/drivers/acpi/pci_link.c
@@ -780,11 +780,6 @@ static int acpi_pci_link_resume(struct a
 		return 0;
 }
 
-/*
- * FIXME: this is a workaround to avoid nasty warning.  It will be
removed
- * after every device calls pci_disable_device in .resume.
- */
-int acpi_in_resume;
 static int irqrouter_resume(struct sys_device *dev)
 {
 	struct list_head *node = NULL;
@@ -794,7 +789,6 @@ static int irqrouter_resume(struct sys_d
 	/* Make sure SCI is enabled again (Apple firmware bug?) */
 	acpi_set_register(ACPI_BITREG_SCI_ENABLE, 1,
ACPI_MTX_DO_NOT_LOCK);
 
-	acpi_in_resume = 1;
 	list_for_each(node, &acpi_link.entries) {
 		link = list_entry(node, struct acpi_pci_link, node);
 		if (!link) {
@@ -803,7 +797,6 @@ static int irqrouter_resume(struct sys_d
 		}
 		acpi_pci_link_resume(link);
 	}
-	acpi_in_resume = 0;
 	return 0;
 }
 
diff --git a/drivers/acpi/utilities/utalloc.c
b/drivers/acpi/utilities/utalloc.c
index 5cff17d..f6cbc0b 100644
--- a/drivers/acpi/utilities/utalloc.c
+++ b/drivers/acpi/utilities/utalloc.c
@@ -285,6 +285,7 @@ acpi_ut_initialize_buffer(struct acpi_bu
 	return (status);
 }
 
+#ifdef NOT_USED_BY_LINUX
 
/***********************************************************************
********
  *
  * FUNCTION:    acpi_ut_allocate
@@ -360,3 +361,4 @@ void *acpi_ut_allocate_zeroed(acpi_size 
 
 	return (allocation);
 }
+#endif
diff --git a/include/acpi/acmacros.h b/include/acpi/acmacros.h
index f1ac610..192fa09 100644
--- a/include/acpi/acmacros.h
+++ b/include/acpi/acmacros.h
@@ -724,9 +724,15 @@ #ifndef ACPI_DBG_TRACK_ALLOCATIONS
 
 /* Memory allocation */
 
+#ifndef ACPI_ALLOCATE
 #define ACPI_ALLOCATE(a)
acpi_ut_allocate((acpi_size)(a),_COMPONENT,_acpi_module_name,__LINE__)
+#endif
+#ifndef ACPI_ALLOCATE_ZEROED
 #define ACPI_ALLOCATE_ZEROED(a)
acpi_ut_allocate_zeroed((acpi_size)(a),
_COMPONENT,_acpi_module_name,__LINE__)
-#define ACPI_FREE(a)                kfree(a)
+#endif
+#ifndef ACPI_FREE
+#define ACPI_FREE(a)                acpio_os_free(a)
+#endif
 #define ACPI_MEM_TRACKING(a)
 
 #else
diff --git a/include/acpi/platform/aclinux.h
b/include/acpi/platform/aclinux.h
index 3f853ca..e0eacfa 100644
--- a/include/acpi/platform/aclinux.h
+++ b/include/acpi/platform/aclinux.h
@@ -104,4 +104,25 @@ #define acpi_thread_id u32
 
 static inline acpi_thread_id acpi_os_get_thread_id(void) { return 0; }
 
+/*
+ * The irqs_disabled() check is for resume from RAM.
+ * Interrupts are off during resume, just like they are for boot.
+ * However, boot has  (system_state != SYSTEM_RUNNING)
+ * to quiet __might_sleep() in kmalloc() and resume does not.
+ */
+static inline void *acpi_os_allocate(acpi_size size) {
+	return kmalloc(size, irqs_disabled() ? GFP_ATOMIC : GFP_KERNEL);
+}
+static inline void *acpi_os_allocate_zeroed(acpi_size size) {
+	return kzalloc(size, irqs_disabled() ? GFP_ATOMIC : GFP_KERNEL);
+}
+
+static inline void *acpi_os_acquire_object(acpi_cache_t * cache) {
+        return kmem_cache_zalloc(cache, irqs_disabled() ? GFP_ATOMIC :
GFP_KERNEL);
+}
+
+#define ACPI_ALLOCATE(a)	acpi_os_allocate(a)
+#define ACPI_ALLOCATE_ZEROED(a)	acpi_os_allocate_zeroed(a)
+#define ACPI_FREE(a)		kfree(a)
+
 #endif				/* __ACLINUX_H__ */