Date: Fri, 3 Nov 2006 10:35:28 +0000 From: MQ <antinvidia@gmail.com> To: "Max Laier" <max@love2party.net> Cc: freebsd-net@freebsd.org Subject: Re: Reentrant problem with inet_ntoa in the kernel Message-ID: <be0088ce0611030235m4739456ek7681f6303543d366@mail.gmail.com> In-Reply-To: <200611021232.45858.max@love2party.net> References: <be0088ce0611020026y4fe07749pd5a984f8744769b@mail.gmail.com> <20061102102807.GA23553@zen.inc> <4549C93A.9080308@delphij.net> <200611021232.45858.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
2006/11/2, Max Laier <max@love2party.net>: > > On Thursday 02 November 2006 11:32, LI Xin wrote: > > VANHULLEBUS Yvan wrote: > > > On Thu, Nov 02, 2006 at 06:19:43PM +0800, LI Xin wrote: > > > [.....] > > > > > >> Sounds like a workaround to me and in theory that is insufficient > > >> for a MPSAFE protection. Here is a patch which reduces the chance > > >> where we get a race. > > > > > > Hi. > > > > > > This patch will allow multiple calls to inet_ntoa int the same > > > function (like printf(....., inet_ntoa(a), inet_ntoa(b))), but won't > > > really solve the race condition if inet_ntoa is called from 2 > > > differents functions at the same time: at least the round should be > > > locked to reduce potential problems, and you're still not sure that > > > no more than 8 "simultaneous" (or at least close enough) calls will > > > be done. > > > > True. That's exactly what I concern about, it just reduced the chance > > we lose a race, not to eliminate it. > > > > Note that the code is similar with what was found in ip6_sprintf, so it > > got same issue I think. > > Just what I was trying to say in my initial, cut-off reply. The question > we have to answer is, how much do we care about logging / console printfs > of IP numbers. AFAIK, console printf isn't (?wasn't?) synchronized > properly, either. In the end the caller has to decide how much it cares > about the result. Security related logging facilities should certainly > use a private buffer (or better yet, do the conversion in userland). All > I'm argueing is, that we should be aware of the sideeffects (substantial > grow in stack size) of the suggested patch and weight it carefully > against the benefit (100% correctness in the unlikeliest of cases). I > think that we can live with a 8 slot ring buffer for most of the cases. > Fixing the race on the round counter seems essential, however. > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News > > > By the way, maybe printf should get better synchronized. When I was addressing some problems in the bge(4), the ill-synchronized printf made my console freezing before I restarted the machine.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?be0088ce0611030235m4739456ek7681f6303543d366>