From: Pavel Machek <pavel@ucw.cz>
To: "Brown, Len" <len.brown@intel.com>
Cc: Andrew Morton <akpm@osdl.org>,
johnstul@us.ibm.com, linux-kernel@vger.kernel.org,
linux-acpi@vger.kernel.org, linux-pm@lists.osdl.org
Subject: Re: [BUG] sleeping function called from invalid context during resume
Date: Sat, 8 Jul 2006 02:30:03 +0200 [thread overview]
Message-ID: <20060708003003.GE1700@elf.ucw.cz> (raw)
In-Reply-To: <CFF307C98FEABE47A452B27C06B85BB6ECF8BD@hdsmsx411.amr.corp.intel.com>
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
next prev parent reply other threads:[~2006-07-08 0:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-08 0:21 [BUG] sleeping function called from invalid context during resume Brown, Len
2006-07-08 0:21 ` Brown, Len
2006-07-08 0:30 ` Pavel Machek [this message]
2006-07-08 0:45 ` [linux-pm] " Alan Stern
2006-07-08 0:45 ` Alan Stern
-- strict thread matches above, loose matches on Subject: below --
2006-07-10 15:51 Brown, Len
2006-07-10 16:01 ` Alan Stern
2006-07-10 5:48 Brown, Len
2006-07-10 5:48 ` Brown, Len
2006-07-07 16:32 Brown, Len
2006-07-07 16:32 ` Brown, Len
2006-07-07 19:40 ` Andrew Morton
2006-07-07 3:10 Brown, Len
2006-07-07 3:10 ` Brown, Len
2006-07-07 3:51 ` Andrew Morton
2006-07-07 3:01 john stultz
2006-07-07 3:32 ` Parag Warudkar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060708003003.GE1700@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=akpm@osdl.org \
--cc=johnstul@us.ibm.com \
--cc=len.brown@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.