Date: Tue, 16 Jan 2018 08:43:45 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-pf@FreeBSD.org Subject: [Bug 209475] pf didn't check if enough free RAM for net.pf.states_hashsize Message-ID: <bug-209475-17777-eEhMJnZC0o@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-209475-17777@https.bugs.freebsd.org/bugzilla/> References: <bug-209475-17777@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209475 --- Comment #11 from Kristof Provost <kp@freebsd.org> --- (In reply to fehmi noyan isi from comment #10) Yes, but I wouldn't check the free memory. I've not yet looked at the code, but the original report suggests there are= a couple of related issues: > kldload stuck and never give the console back on my 8GB RAM server This suggests that pf is doing an allocation with M_WAITOK. This means the malloc() call will keep waiting until enough memory is found to satisfy the request. If that's for more memory than is available it'll never return > During this status, issuing command "pfctl" will crash the system: This suggests that there's a race in pf initialisation where the ioctl() handler is already registered before all initialisation is done (i.e. the l= arge allocation is still blocked). That's a bug too, and one that could potentia= lly occur even if the large allocation succeeds (though in a very small time window). My initial approach would be to find the allocation that blocks startup, presumably where the state hash table is allocated, and remove the M_WAITOK flag. Then the code needs to be changed to ensure that it can handle an allocation failure. The second step is to audit the initialisation code to find out why ioctls() can be done before the state hash table is allocated. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-209475-17777-eEhMJnZC0o>