Date: Thu, 25 Feb 2016 13:18:38 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Kristof Provost <kp@FreeBSD.org> Cc: Conrad Meyer <cem@FreeBSD.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r296025 - head/sys/netpfil/pf Message-ID: <20160225111838.GC67250@kib.kiev.ua> In-Reply-To: <20160225102617.GG3003@vega.codepro.be> References: <201602250733.u1P7Xxoh041746@repo.freebsd.org> <CAJ-Vmok_-SzGnUdYi%2BnnDYdGhcKXOUthC1nnPyxHrnWJCKA%2Bcw@mail.gmail.com> <CAG6CVpWwidL6S90fnThc7mXp9sj3PbJB6rvkBN=MmbvFS%2B_vtw@mail.gmail.com> <20160225091741.GF3003@vega.codepro.be> <20160225100757.GA67250@kib.kiev.ua> <20160225102617.GG3003@vega.codepro.be>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 25, 2016 at 11:26:18AM +0100, Kristof Provost wrote: > That's a good point. We could handle those accesses failing, but > sleeping with the PF_RULES_WLOCK held would be a bad idea. > > I suppose we could just change M_WAITOK into M_NOWAIT and return ENOMEM > if it fails. The only downside I can see is that it's more likely for a > call to fail if there's not a lot of free memory. As you rightfully noted, use of M_NOWAIT at the top-half of the kernel causes random user-visible failures, which are caused by unrelated events and its interaction with the pagedaemon activities. Typical kernel code applies somewhat more complex algorithms to e.g. calculate the memory requirements, drop the locks and alloc everything, then re-acquire the locks and recheck the conditions. > > There's actually a decent number of cases where that'd have to be done, > but it doesn't look particularly hard to do.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160225111838.GC67250>