After some earlier email with Alan Cox, it seems that sti/cli is overkill
for these proc routines. proc routines need to lock the tables against
changes while they generate the output, they currently use cli/sti. In
many cases (I'd like to say all cases but have not had time to check all
the code), the real requirement is to lock out the bottom half handlers,
still allowing physical interrupts.
Replacing cli/sti with start_bh_atomic/end_bh_atomic will at least allow
physical interrupts to be handled. However those macros lock out all
bottom halves, not just the ones that hit the tables. There are macros
that lock out specific bottom halves (disable/enable_bh) so it should be
possible to just disable (say) NET_BH around the critical network code,
letting other bottom halves run. This would be a big improvement over
cli/sti.
Alas a cursory check of the code shows that we would also have to disable
TIMER_BH because some tables are updated by timer expiration (e.g.
masq_timer). AFAIK the timer routines run under TIMER_BH, even though
they update net (and other) tables. Should we change the timer code to
associate timer routines with the relevant code sections or do we just
disable TIMER_BH as well as (say) NET_BH?
As we head towards a granulated kernel lock, this problem has to be
addressed globaly, not just for /proc routines. Since BH routines are not
allowed to sleep, one solution is not to schedule them until their
resources are free, i.e. the relevant BH routine must be enabled. This
needs a BH number for each timer entry, the timer code would mark the
relevant BH as pending, instead of just marking TIMER_BH.
In the meantime, I'll try enable/disable_bh TIMER and NET around some proc
routines, see if there are any problems.