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

Reply via email to