Bill Fenner wrote: > I think most of your 9k of reasoning is based on the thought that > soreserve() allocates memory. It doesn't, and never has.
The real problem is the in_pcballoc() in tcp_attach(), which calls uma_zalloc(). But for mbufs, soreserve allocates space, for potential mbufs, even though it does not itself allocate mbufs. I didn't want to go through the whole state machine to explain the additional failure modes, so I simplified. Consider the case where you receive network interrupts for packets containing data on partially complete, or in-the-process-of sockets, while you are in the middle of running the NETISR. This code was not written to be reentrant in the failure case, and the SYN cache adds this requirement. The only "safe" way to do this, with the code unmodified, is to hold splbio() around the calls, and split the "if" test I modified into an if .. if..else .. else if..else. Even then, it doesn't make one call that give a binary success/fail. As evidence, I offer that my fix works, too, by changing the order of operation. 8-). Note that I'm not complaining about your fix any more than I'm complaining about mine -- in fact, I have stated repeatedly for the record that your fix has one less failure mode than my fix, and should be committed. Potentially, both of them should be committed (for the SYN cache disable case, mine suppresses another panic, for the other, yours suppresses a different panic, and "enabled" is the common case). It's just that neither address the real problem, they just suppress the side effect of a side effect, in different ways. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message