[lkml]   [2000]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: lock_kernel() & kmalloc - evil together?
On Thu, Aug 10, 2000 at 04:57:07PM -0500, Sam Watters wrote:
> Okay, I screwed up in a patch I am doing and I put slipped in some
> kmalloc(GFP_KERNEL) calls in a segment of code that lies between a
> lock_kernel()/unlock_kernel() - specifically in do_fork(). I did find some
> other kmalloc(GFP_KERNEL) calls that occur in this same segment (in functions
> that get called from do_fork()). So, am I truly evil for adding these new
> kmalloc(GFP_KERNEL) calls? Any suggestions on how best to allocate memory while

You're not evil, the kernel lock is magic and the scheduler drops it when
entered (it is just used to get cooperative multitasking like in 2.0). There
fore you're allowed to sleep. This is not true for other spinlocks.

When you cannot sleep you should use kmalloc(..., GFP_ATOMIC), but it is
less reliable than GFP_KERNEL.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:58    [W:0.058 / U:4.472 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site