| Summary: | [tcp] [panic] [patch] hostcache: supervisor read, page not present | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Oleg Koreshkov <okor> | ||||
| Component: | kern | Assignee: | Andre Oppermann <andre> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | ||||||
| Priority: | Normal | ||||||
| Version: | 6.3-RELEASE | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
|
Description
Oleg Koreshkov
2008-04-14 11:00:09 UTC
Responsible Changed From-To: freebsd-bugs->freebsd-net Over to maintainer(s). Responsible Changed From-To: freebsd-net->andre Take over. State Changed From-To: open->closed While the handling of over-sized hash tables isn't great, I think it's more likely that this crash was caused by the bug fixed in the following revision to tcp_hostcache.c: r170405 | andre | 2007-06-07 22:41:50 +0100 (Thu, 07 Jun 2007) | 9 lines In tcp_hc_insert() we may have the case where we have hit the global cache size limit but this bucket row is empty. Normally we want to recycle the oldest entry in the bucket row. If there isn't any the TAILQ_REMOVE leads to a panic by trying to remove a non-existing element. Fix this by just returning NULL and failing the insert. This is not a problem as the TCP hostache is only advisory. Submitted by: jhb And MFC'd: r181015 | jhb | 2008-07-30 21:52:12 +0100 (Wed, 30 Jul 2008) | 4 lines MFC: If we hit the global cache size limit but the bucket row is empty then we won't find an entry to recycle, so just return NULL and fail the insert. That is to say: the bug wasn't in the table being too large, but in the handling of an over-full table of a larger size. This fix was merged to FreeBSD 6.x prior to FreeBSD 6.4. I'm closing the PR on the basis that the reported bug is fixed, but we should consider ways to improve oversize hash configurations, which are typically reported by panics during boot. If this problem recurs, please follow up on the PR and I will reopen it. Thanks for the bug report! |