lkml.org 
[lkml]   [2000]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: lock_kernel() & kmalloc - evil together?
       Date: 	Fri, 11 Aug 2000 14:06:48 -0700 (PDT)
    From: Linus Torvalds <torvalds@transmeta.com>

    On Fri, 11 Aug 2000, Jeff V. Merkey wrote:
    >
    > Thanks! This is good to know. This means if I use it inside of
    > spinlock_irqsave() outside an interrupt, it will tell me not to context
    > switch .... Need to look at this.

    It's wrong.

    It _can_ return false positives, but only
    - for a _globally_ disabled irq region
    - and only on SMP.

    Basically, the rule is that if you use a global cli/sti region, all bets
    are off.

    Hopefully only for the cpu which called the global cli() function,
    right?

    Or are you saying that if one kernel thread on one CPU calls
    in_interrupt() while some other kernel thread on some other CPU has
    called cl(), the CPU's call to in_interrupt may return a false positive?

    If that's the case, then in_interrupt() only has meaning if it returns
    false. If it returns true, you have no idea whether it's because you
    really are in an interrupt, or some other CPU has called cli(). I hope
    that's not the case....

    - Ted

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:58    [W:0.020 / U:30.540 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site