Date: Fri, 01 Nov 2002 17:08:40 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Bill Fenner <fenner@research.att.com> Cc: mime@traveller.cz, current@FreeBSD.ORG Subject: Re: crash with network load (in tcp syncache ?) Message-ID: <3DC32598.A0D0909A@mindspring.com> References: <200211012246.gA1Mki5n001478@stash.attlabs.att.com> <3DC31EB0.2B79F42E@mindspring.com> <200211020100.RAA10356@windsor.research.att.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bill Fenner wrote: > >I think this can still crash (just like my patch); the problem is in > >what happens when it fails to allocate memory. Unless you set one of > >the flags, it's still going to panic in the same place, I think, when > >you run out of memory. > > No. The flags are only checked when so_head is not NULL. sonewconn() > was handing sofree() an inconsistent struct so (so_head was set without > being on either queue), i.e. sonewconn() was creating an invalid data > structure. You're right... I missed that; I was thinking too hard on the other situations (e.g. soabort()) that could trigger that code, and no enough on the code itself. > The call in sonewconn() used to be to sodealloc(), which didn't care > about whether or not the data structure was self-consistent. The code > was refactored to do reference counting, but the fact that the socket > was inconsistent at that point wasn't noticed until now. Yeah; I looked at doing a ref() of the thing as a partial fix, but the unref() did the sotryfree() anyway. > The problem is not at all based on what happens in the allocation or > protocol attach failure cases. The SYN cache is not involved, this is > a bug in sonewconn(), plain and simple. I still think there is a potential failure case, but the amount of code you'd have to read through to follow it is immense. It has to do with the conection completing at NETISR, instead of in a process context, in the allocation failure case. I ran into the same issue when trying to run connections to completion up to the accept() at interrupt, in the LRP case. The SYN cache case is very similar, in the case of a cookie that hits when there are no resources remaining. He might be able to trigger it with his setup, by setting the cache size way, way don, and thus relying on cookies, and then flooding it with conection requests until he runs it out of resources. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DC32598.A0D0909A>