> On 28 Apr 2023, at 15:38, Alexander Bluhm <alexander.bl...@gmx.net> wrote: > > On Fri, Apr 28, 2023 at 02:51:23PM +0300, Vitaliy Makkoveev wrote: >>> On 28 Apr 2023, at 14:03, Alexander Bluhm <alexander.bl...@gmx.net> wrote: >>> >>> That basically means we must never call one of the pool get or put >>> functions with kernel lock. This may be the case currently. But >>> at this stage while we are pushing locks around the network code, >>> I would like to keep it as it is. >>> >>> Allowing net interrupts during route pool get mutex gains nearly >>> nothing. It makes placing a kernel lock in our transition process >>> harder. >>> >>> bluhm >> >> This is not true. The IPL is not kerne lock or MP related. Each pool(9) >> uses its own mutex(9) or rwlock(9) for protection. > > mpi@ told me the following background of IPL_MPFLOOR: > > The reasoning is lock ordering with mutex and kernel lock. If you > take mutex sometimes with and sometimes without kernel lock the > following can happen. > > - cpu 1 takes kernel lock > - cpu 1 takes mutex > > - cpu 2 takes mutex without kernel lock > - cpu 2 is interrupted > - cpu 2 interrupt handler takes kernel lock > > And here you have a deadlock. There are three solutions >
Thanks for explanation.
