But only if the interrupt handler did mark_bh() in the first place.
True, return_syscall will call do_bottom_half() if *any* BH bit is set
but do_bottom_half() only calls BH routines if their *specific* bit is
set. Something has to mark_bh(specific bit) at some stage or the data
for that bit will just sit there.
>Besides, it seems to me that the argument has been over not processing
>BH's in after running an interrupt handler *which won't register/mark
>active a BH in the first place*. The so-called "fast interrupts" that
>people still seem to believe in.
If one is not registered that is fine, no work to do anyway, lose a few
cycles running the bit map. But if a BH has been registered then
sooner or later, something has to mark_bh(). It is all very well
delaying a BH until (say) 10 interrupts have arrived but what if we
only get 9 interrupts? There has to be a bounded delay on running any
delayed BH.
-
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/