[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130613190610.GA13970@mtj.dyndns.org>
Date: Thu, 13 Jun 2013 12:06:10 -0700
From: Tejun Heo <tj@...nel.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Kent Overstreet <koverstreet@...gle.com>,
linux-kernel@...r.kernel.org, Oleg Nesterov <oleg@...hat.com>,
Christoph Lameter <cl@...ux-foundation.org>,
Ingo Molnar <mingo@...hat.com>,
Andi Kleen <andi@...stfloor.org>, Jens Axboe <axboe@...nel.dk>,
"Nicholas A. Bellinger" <nab@...ux-iscsi.org>
Subject: Re: [PATCH] Percpu tag allocator
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists