Re: kmalloc without GFP_xxx?

Denis Vlasenko
2005-06-30T07:53:20Z

On Wednesday 29 June 2005 19:48, Timur Tabi wrote:
> Denis Vlasenko wrote:
>
> > This is why I always use _irqsave. Less error prone.
>
> No, it's just bad programming. How hard can it be to see which spinlocks are being used
> by your ISR and which ones aren't? Only the ones that your ISR touches should have
> _irqsave. It's really quite simple.

Given that I do not touch core kernel and most of spinlocks I ever
did were in drivers - yes, they are there to protect me from IRQ
handler races.

> > This is more or less what I meant. Why think about each kmalloc and when you
> > eventually did get it right: "Aha, we _sometimes_ get called from spinlocked code,
> > GFP_ATOMIC then" - you still do atomic alloc even if cases when you
> > were _not_ called from locked code! Thus you needed to think longer and got
> > code which is worse.
>
> So you're saying that you're the kind of programmer who makes more mistakes the longer you
> think about something?????

No.

I say that writing kmalloc(size, GFP_ATOMIC) takes more time to verify
that it is needed compared to hypothetical kmalloc_auto(size),
and yet kmalloc(size, GFP_ATOMIC) is worse in a sense thet it won't sleep
even if it happens to be called outside locks.

Think about this:

/* may be called under spinlock */
void do_something() {
/* we need to alloc here */
}

> Using GFP_ATOMIC increases the probability that you won't be able to allocate the memory
> you need, and it also increases the probability that some other module that really needs
> GFP_ATOMIC will also be unable to allocate the memory it needs. Please tell me, how is
> this considered good programming?

Where did I say "let's use GFP_ATOMIC everywhere" ?
--
vda