Just a question: can kfree sleep?
I believe so, but slab.c does not enlighten me immediately:
void
kfree (const void *objp)
{
kmem_cache_t *c;
unsigned long flags;
if (!objp)
return;
local_irq_save (flags);
c = GET_PAGE_CACHE (virt_to_page (objp));
__cache_free (c, (void *) objp);
local_irq_restore (flags);
}
static inline void __cache_free (kmem_cache_t *cachep, void* objp)
{
struct array_cache *ac = ac_data(cachep);
check_irq_off();
objp = cache_free_debugcheck(cachep, objp, __builtin_return_address(0));
if (likely(ac->avail < ac->limit)) {
STATS_INC_FREEHIT(cachep);
ac_entry(ac)[ac->avail++] = objp;
return;
} else {
STATS_INC_FREEMISS(cachep);
cache_flusharray(cachep, ac);
ac_entry(ac)[ac->avail++] = objp;
}
}
...
Peter
Hi Peter,
>Just a question: can kfree sleep?
>
>
>
>
No, it never sleeps. It's safe to call kfree from arbitrary context. The
only exception is the NMI oopser and similar arch code.
>I believe so, but slab.c does not enlighten me immediately:
>
>
Yes, the kfree code is quite long - it must check if freeing one object
created a freeable page and return it to the page allocator. Together
with lots of caching and debug checks.
--
Manfred
In article <[email protected]> you wrote:
> Hi Peter,
Hi!
> >Just a question: can kfree sleep?
> >
> No, it never sleeps. It's safe to call kfree from arbitrary context. The
> only exception is the NMI oopser and similar arch code.
OK - thanks. I'll take that as read and eliminate kfree from the list
of sleep "seeds" in my code analyser.
> >I believe so, but slab.c does not enlighten me immediately:
> >
> Yes, the kfree code is quite long - it must check if freeing one object
> created a freeable page and return it to the page allocator. Together
> with lots of caching and debug checks.
May I ask where your knowledge of this comes from? (So I can duplicate
the learning process)!
Peter
"Peter T. Breuer" <[email protected]> wrote:
>
> Just a question: can kfree sleep?
Nope. All memory freeing codepaths are atomic and may be called from any
context except NMI handlers.
On Sun, Nov 21, 2004 at 01:10:38PM -0800, Andrew Morton wrote:
> Nope. All memory freeing codepaths are atomic and may be called from any
> context except NMI handlers.
Not true for vfree()
In article <[email protected]> you wrote:
> On Sun, Nov 21, 2004 at 01:10:38PM -0800, Andrew Morton wrote:
> > Nope. All memory freeing codepaths are atomic and may be called from any
> > context except NMI handlers.
>
> Not true for vfree()
My interest at the moment is in what can sleep and what cannot sleep.
Are you saying that vfree can sleep or that vfree cannot be called from
at least one other context in addition to the NMI handler context (from
which it cannot be called ...)?
:)
Peter
On Sun, Nov 21, 2004 at 11:30:38PM +0100, Peter T. Breuer wrote:
> In article <[email protected]> you wrote:
> > On Sun, Nov 21, 2004 at 01:10:38PM -0800, Andrew Morton wrote:
> > > Nope. All memory freeing codepaths are atomic and may be called from any
> > > context except NMI handlers.
> >
> > Not true for vfree()
>
> My interest at the moment is in what can sleep and what cannot sleep.
> Are you saying that vfree can sleep or that vfree cannot be called from
> at least one other context in addition to the NMI handler context (from
> which it cannot be called ...)?
vfree can't sleep, but it can't be called from every context.
> > Not true for vfree()
>
> My interest at the moment is in what can sleep and what cannot sleep.
> Are you saying that vfree can sleep or that vfree cannot be called from
> at least one other context in addition to the NMI handler context (from
> which it cannot be called ...)?
vfree() is not allowed to be called from irq context, and since it can do cross cpu IPI's, you have to generally be careful with it.