>> >> 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
-
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]
