From: Tejun Heo <tj@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Kent Overstreet <koverstreet@google.com>,
linux-kernel@vger.kernel.org, Oleg Nesterov <oleg@redhat.com>,
Christoph Lameter <cl@linux-foundation.org>,
Ingo Molnar <mingo@redhat.com>, Andi Kleen <andi@firstfloor.org>,
Jens Axboe <axboe@kernel.dk>,
"Nicholas A. Bellinger" <nab@linux-iscsi.org>
Subject: Re: [PATCH] Percpu tag allocator
Date: Thu, 13 Jun 2013 12:06:10 -0700 [thread overview]
Message-ID: <20130613190610.GA13970@mtj.dyndns.org> (raw)
In-Reply-To: <20130612163854.91da28042ab7a943b69a5970@linux-foundation.org>
Hello, Andrew, Kent.
On Wed, Jun 12, 2013 at 04:38:54PM -0700, Andrew Morton wrote:
...
> > +unsigned percpu_tag_alloc(struct percpu_tag_pool *pool, gfp_t gfp)
> > +{
> > + DEFINE_WAIT(wait);
> > + struct percpu_tag_cpu_freelist *tags;
> > + unsigned long flags;
> > + unsigned tag, this_cpu;
> > +
> > + while (1) {
> > + local_irq_save(flags);
...
> > + schedule();
> > + }
>
> Does this loop need a try_to_freeze()?
I don't think so. Kernel tasks should never enter freezer without it
explicitly knowing it. It should be something evident in the
top-level control flow. Freezer acts as a giant lock and entering
freezer deep underneath where the task could be holding random number
of resources and locks can easily develop into a deadlock.
If this allocation wait is gonna be visible to userland, what's
necessary probably would be making the sleeping interruptible. The
freezer will then make the alloc fail and control should return to the
signal delivery path where it'll be frozen without holding any
resources.
Thanks.
--
tejun
next prev parent reply other threads:[~2013-06-13 19:06 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-12 4:03 Kent Overstreet
2013-06-12 17:08 ` Oleg Nesterov
2013-06-12 17:59 ` Kent Overstreet
2013-06-12 19:14 ` Oleg Nesterov
2013-06-12 23:38 ` Andrew Morton
2013-06-13 2:05 ` Kent Overstreet
2013-06-13 3:03 ` Andrew Morton
2013-06-13 3:54 ` Kent Overstreet
2013-06-13 5:46 ` Andrew Morton
2013-06-13 18:53 ` Tejun Heo
2013-06-13 19:04 ` Andrew Morton
2013-06-13 19:15 ` Tejun Heo
2013-06-13 19:23 ` Andrew Morton
2013-06-13 19:35 ` Tejun Heo
2013-06-13 22:10 ` Andrew Morton
2013-06-13 22:30 ` Tejun Heo
2013-06-13 22:35 ` Andrew Morton
2013-06-13 23:13 ` Tejun Heo
2013-06-13 23:23 ` Tejun Heo
2013-06-19 1:32 ` Kent Overstreet
2013-06-13 19:08 ` J. Bruce Fields
2013-06-13 19:09 ` Jeff Layton
2013-06-13 21:53 ` Kent Overstreet
2013-06-13 19:06 ` Tejun Heo [this message]
2013-06-13 19:13 ` Andrew Morton
2013-06-13 19:21 ` Tejun Heo
2013-06-13 21:14 ` Kent Overstreet
2013-06-13 21:50 ` Tejun Heo
2013-06-13 21:58 ` Kent Overstreet
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=20130613190610.GA13970@mtj.dyndns.org \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=axboe@kernel.dk \
--cc=cl@linux-foundation.org \
--cc=koverstreet@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nab@linux-iscsi.org \
--cc=oleg@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®