On Fri, Jul 31, 2020 at 10:25:48PM +0200, Martin Pieuchot wrote: > On 31/07/20(Fri) 21:58, Vitaliy Makkoveev wrote: > > [...] > > What denies us to move pipex(4) under it's own lock? > > Such question won't lead us anywhere. It assumes it makes sense to move > pipex under its own lock. This assumption has many drawback which clearly > haven't been studied and more importantly it doesn't explains what for. > > What is your goal? What are you trying to achieve? Improve latency? > Improve performances? Of which subsystem? Where is the bottleneck? > What is the architecture of the system? >
If I understood Yasuoka correctly kthread "crynlk" is the bottleneck and he wish MPPE be offloaded to another cpu. Since there is no simultaneous execution of crypto thread and pipexintr() which do MPPE stuff, the easiest way to reach it is to move pipex(4) under another lock. I don't mean "stop everything and implement now", I mean we can do it in the future. If there is no bottleneck in crypto thread, I see no reason to not remove pipexintr(). If the bottleneck is the crypto thread, I propose to implement refcounters to fix issue. And finish this thread. > IMHO the KERNEL_LOCK() should be removed an anything else postponed at > least until one has a clear understanding of the whole subsystem under > the NET_LOCK(). > The whole subsystem is under NET_LOCK() now. Just after we fix use after free issue we can start to move pipex(4) out of KERNEL_LOCK().
