[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.020 / U:11.920 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site