lkml.org 
[lkml]   [1999]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectSMP problem with (en|dis)able_bh().
Hi!

There is a problem with (en|dis)able_bh(). The problem is that if these
calls are not protected by some other locking mechanism, things might not
work correctly on SMP machines.

The routines look like this (in 2.2.0-pre6, file include/asm-i386/softirq.h):

extern inline void disable_bh(int nr)
{
bh_mask &= ~(1 << nr);
atomic_inc(&bh_mask_count[nr]);
synchronize_bh();
}

extern inline void enable_bh(int nr)
{
if (atomic_dec_and_test(&bh_mask_count[nr]))
bh_mask |= 1 << nr;
}

Now imagine the situation when processor A is going to disable bottom
halves, while B is going to enable it. Now it might go like this (note
that many other similar scenarios are possible):

A clears the bit in bh_mask

B decrements bh_mask_count

B sets the bit in bh_mask

A increments bh_mask_count

So, the result is that A thinks that the particular bottom half handler is
disabled but it actually is not.

Thus if there is no global lock protecting these calls, this will cause
problems. I would bet that especially CONSOLE_BH might suffer from this.

Note that from all supported architectures, only sparc32 does not have
this problem, as it uses its own spinlock to protect all functions
dealing with bottom half handlers, without making any further assumptions.

Finally, note that this problem affects only SMP boxes, as long as these
calls are not allowed to be called from an interrupt.

I would suggest that it is explicitly stated somewhere what conditions
must be met when using all these bh calls (and perhaps some others, like
those in hardirq.h), and the corresponding code is revised to meet
specified requirements. Anyone going to state these conditions?

Patrik


-
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:49    [W:0.288 / U:0.716 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site