rcu / rcu_bh and ddos

[Vincent Ray]

Hello Linux hackers, 

I was reading some kernel code and documentation, and came to learn about the RCU mechanism. 
I think I've more or less understood what it is and how it works, but still something puzzles me : 

Why is the *_bh flavor not used pretty much everywhere ? I mean, at least where the "classic" flavor is used (not dealing with srcu or rcu_sched for now ...) 

If I undestand well, rcu_read_lock_bh and friends protect us from ddos style attacks where one or more CPUs may loop executing only soft-irqs forever. 
They do that by : 
- disabling soft-irqs inside the read-side critical sections 
- and consider that completing a soft-irq is a transition to quiescent state, in addition to context switching 

Yet I see that rcu_read_lock is far more employed in the kernel than rcu_read_lock_bh is, the latter being apparently restricted to the net subsystem area. 

What I don't get is : sure ddos attacks can be related to the net area (e.g. with someone flooding us with small packets), but why would kernel code dealing with other things be immune to such attacks ? 
I mean : what if some code in the kernel, maybe dealing with the implementation of a particular scall (having nothing to do with the net subsystem), uses rcu_read_lock(), and then our system suffers a ddos attack, leading one of our CPUs to remain in a soft-irq loop forever ? 
Wouldn't that mean that the thread performing the related synchronize_rcu() would never finish ? 
And then we would be deadlocked by this ddos attack, although the "victim" rcu was made from a place / on a structure that has nothing to do with the network itself ? 

Obviously I must be missing something otherwise *_bh would be used everywhere .... 
Can you enlighten me ? 

Thanks a lot ! 

Vincent Ray 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20220428/ab154596/attachment.html>