From: Kirill Korotaev <dev@sw.ru>
To: Paul Jackson <pj@sgi.com>
Cc: torvalds@osdl.org, simon.derr@bull.net,
linux-kernel@vger.kernel.org, den@sw.ru, st@sw.ru,
Andrew Morton <akpm@osdl.org>
Subject: Re: cpusets: BUG: cpuset_excl_nodes_overlap() may sleep under tasklist_lock
Date: Wed, 04 Jan 2006 12:26:05 +0300 [thread overview]
Message-ID: <43BB94AD.8090909@sw.ru> (raw)
In-Reply-To: <20060103143158.8ab385d0.pj@sgi.com>
>>FYI, there is an obvious bug in cpusets in 2.6.15-rcX:
>>cpuset_excl_nodes_overlap() may sleep (as it takes semaphore), but is
>>called from atomic context - select_bad_process() under tasklist_lock.
>>BUG. Found by Denis Lunev.
>
>
> Sorry for not responding sooner - I was off the air for a week.
>
> Thanks for finding and reporting this.
>
> Apparently, from KUROSAWA Takahiro's report, this bug was also in
> 2.6.14. My initial reading of the code in 2.6.14 and 2.6.15-* agrees,
> and finds that this bug was present since the cpuset_excl_nodes_overlap
> call was added, Sept 8, 2005 (in Linus's tree.)
>
>
>
>>the same actually applies to cpuset_zone_allowed() which is called e.g.
>>from __alloc_pages()->get_page_from_freelist() and doesn't check for
>>GPF_NOATOMIC anyhow...
>
>
> I don't think so. Please read the comments in kernel/cpuset.c above
> the routine cpuset_zone_allowed(). Either that routine is called with
> the __GFP_HARDWALL flag set, so returns before it gets to the semaphore
> call, or it is not called at all, due to the check for ATOMIC (!wait)
> in mm/page_alloc.c.
>
> I don't see any bugs like this, in the cpuset_zone_allowed code path.
this piece of code in __alloc_pages():
if (((p->flags & PF_MEMALLOC) ||
unlikely(test_thread_flag(TIF_MEMDIE)))
&& !in_interrupt()) {
if (!(gfp_mask & __GFP_NOMEMALLOC)) {
nofail_alloc:
/* go through the zonelist yet again, ignoring
mins */
page = get_page_from_freelist(gfp_mask, order,
zonelist,
ALLOC_NO_WATERMARKS|ALLOC_CPUSET);
ALLOC_CPUSET is specified, gfp_mask can be GFP_ATOMIC still and no
__GFP_HARDWALL. Am I wrong?
Kirill
next prev parent reply other threads:[~2006-01-04 9:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-28 12:48 cpusets: BUG: cpuset_excl_nodes_overlap() may sleep under tasklist_lock Kirill Korotaev
2006-01-03 22:31 ` Paul Jackson
2006-01-04 9:26 ` Kirill Korotaev [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-01-09 22:42 Darrick J. Wong
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=43BB94AD.8090909@sw.ru \
--to=dev@sw.ru \
--cc=akpm@osdl.org \
--cc=den@sw.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=pj@sgi.com \
--cc=simon.derr@bull.net \
--cc=st@sw.ru \
--cc=torvalds@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.