Date: Thu, 2 Nov 2006 12:32:40 +0100 From: Max Laier <max@love2party.net> To: freebsd-net@freebsd.org Cc: VANHULLEBUS Yvan <vanhu_bsd@zeninc.net>, LI Xin <delphij@delphij.net> Subject: Re: Reentrant problem with inet_ntoa in the kernel Message-ID: <200611021232.45858.max@love2party.net> In-Reply-To: <4549C93A.9080308@delphij.net> References: <be0088ce0611020026y4fe07749pd5a984f8744769b@mail.gmail.com> <20061102102807.GA23553@zen.inc> <4549C93A.9080308@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart2053230.SOOuEtbO6C Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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=20 we have to answer is, how much do we care about logging / console printfs=20 of IP numbers. AFAIK, console printf isn't (?wasn't?) synchronized=20 properly, either. In the end the caller has to decide how much it cares=20 about the result. Security related logging facilities should certainly=20 use a private buffer (or better yet, do the conversion in userland). All=20 I'm argueing is, that we should be aware of the sideeffects (substantial=20 grow in stack size) of the suggested patch and weight it carefully=20 against the benefit (100% correctness in the unlikeliest of cases). I=20 think that we can live with a 8 slot ring buffer for most of the cases. =20 =46ixing the race on the round counter seems essential, however. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2053230.SOOuEtbO6C Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFSdddXyyEoT62BG0RAgqTAJ9nGS0dSdfDWUGw0YIGD8TBRc+lwwCfcAzs i6S1TaWKFyw/gCuK5Vc1zx4= =9ev3 -----END PGP SIGNATURE----- --nextPart2053230.SOOuEtbO6C--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200611021232.45858.max>