Reentrant problem with inet_ntoa in the kernel
Max Laier
max at love2party.net
Thu Nov 2 11:33:11 UTC 2006
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 at freebsd.org
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier at EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20061102/d948dd32/attachment.pgp
More information about the freebsd-net
mailing list