From: torvalds@transmeta.com (Linus Torvalds)
Newsgroups: linux.dev.kernel
Subject: Re: lock_kernel() & kmalloc - evil together?
Date: 11 Aug 00 18:40:36 GMT

On Fri, 11 Aug 2000, Jeff V. Merkey wrote:
>
> Is there a counter of some type in Linux I could check to detect this
> easily?

It's called

	in_interrupt()

in Linux - it's not a single counter, as hard interrupts and soft
interrupts are counted separately, but it gives you the information you
want (whether you're in an interrupt or not).

		Linus

From: torvalds@transmeta.com (Linus Torvalds)
Newsgroups: linux.dev.kernel
Subject: Re: lock_kernel() & kmalloc - evil together?
Date: 11 Aug 00 21:06:48 GMT

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.

Spinlocks do not affect the state - not even if they are of the irq-safe
type.

		Linus

From: tytso@MIT.EDU (Theodore Y. Ts'o)
Newsgroups: linux.dev.kernel
Subject: Re: lock_kernel() & kmalloc - evil together?
Date: 12 Aug 00 01:37:51 GMT

   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

From: torvalds@transmeta.com (Linus Torvalds)
Newsgroups: linux.dev.kernel
Subject: Re: lock_kernel() & kmalloc - evil together?
Date: 12 Aug 00 02:28:53 GMT

In article <200008120137.VAA07065@tsx-prime.MIT.EDU>, Theodore Y. Ts'o <tytso@MIT.EDU> wrote:
>
>   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?

Right.

Basically, the global cli/sti stuff plays games with the interrupt state
and thus potentially the counts.  At least it used to do so - I don't
think the current version does, at least not on x86, but basically it's
not something you should depend on.

Same goes for the softirq variants (ie "bh_disable()" and "bh_enable()")
which really _do_ mess with the counts right now.

		Linus