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.059 / U:1.260 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site