> The point is that we are writing in the asm section of the includes so we
> don't need to write C that works everywhere, but only in all i386.
I know.
> In the init_bh/remove_bh the only thing I care is the order of the
> routine = xx and bh_mask |= xxx operations. Nothing more. It has to be
> single threaded, and I want it atomic in respect only of the bh handler
> engine.
Well it fullfils these assumptions then. But what about SMP boxes? Can't
one processor execute init/remove_bh while the other one runs other
init/remove_bh or enable/disable_bh? It could lead to bh_mask corruption
then because expressions like ( bh_mask |= 1 << nr ) are not atomic.
> When instead we are at regime we only care to do update bh_mask and
> bh_mask_count at the same time, to not risk to have bh_mask_count enabled
> but bh_mask disabled (or the reverse). You must think at enable_bh() and
> disable_bh() as heavily recalled from different context at the same time
> (as in the console code).
I think it's not me who has problem seeing the possible races :)
> I can't see races in get_active_bhs() and clear_active_bhs(). The reason
> is that if we miss a bh this time we'll get it the next one. Can you
> explain better your thought?
I was not talking about bh_active field at all. But when you mention it,
the double locking is not very nice implementation, is it? You can
delay the software interrupt for whole 210 usec, and in theory,
there is a chance you can delay it forever.
BTW, don't you know why m68k does not trigger the software irq line
in mark_bh()? I thought this is what software irq is for...
Patrik
P.S. I do not cc: Linus as it seems he doesn't care anyway...
-
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/