On Tuesday 02 August 2005 19:46, Ingo Oeser wrote: > Daniel Phillips wrote: > > On Tuesday 02 August 2005 07:30, Patrick McHardy wrote: > > > IIRC Linus called the whole swapping over ISCSI idea > > > broken because apparently even userspace needs to allocate memory in > > > some situations to make things work. > > > > Even a user space task may run in PF_MEMALLOC mode (and so guarantee its > > syscalls access to a modest amount of working memory) so long as it > > follows the same rules as a kernel task: all per-request memory usage > > must be statically analyzable and bounded. But I am getting ahead of > > myself: the immediate challenge is to deal accurately with the > > network-receive facet of this multi-facetted problem. > > Imagine a IPsec-SA timing out just in this case and (nearly) > all user space pages swapped out. > > We need to renegotiate an IPsec-SA with someone, which needs the > ISAKMP-daemon, which is completly swapped out. But we have no memory to > swap it in, since we cannot swap out without transferring to our remote > "disk" over an IPsec secured connection.
The problem is that the ISAKMP-daemon was not memlocked, as every piece of user space code sitting in the block IO path needs to be. Not only that, but memory-bounded, and either running in PF_MEMALLOC mode or allocating no memory, even in libraries or syscalls. You would be right to think that there is a lot of code out there violating these conditions, but when you think about them, they are fairly obvious. > Ugly; you see. That kind of things makes Linus shudder, I think. But I've been wallowing in exactly these problems now for two years, and there is no choice but to solve them if we ever want to have, e.g., reliable cluster nodes. I now have all the nasty bits under control (on paper) except for this network bit, which is just about fixed as well, I think. Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
