Skip site navigation (1)Skip section navigation (2)
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>