Date: Sun, 21 May 2006 22:03:14 +0400 (MSD) From: Maxim Konovalov <maxim@macomnet.ru> To: Robert Watson <rwatson@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: HEADS UP: socket and pcb reference changes entering tree today Message-ID: <20060521215823.H6324@mp2.macomnet.net> In-Reply-To: <20060521185034.K8068@fledge.watson.org> References: <20060317141627.W2181@fledge.watson.org> <20060329100839.V19236@fledge.watson.org> <20060401102918.P79188@fledge.watson.org> <20060401170554.R82503@fledge.watson.org> <20060402233436.P76562@fledge.watson.org> <20060515025600.U70399@mp2.macomnet.net> <20060521185034.K8068@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 21 May 2006, 18:55+0100, Robert Watson wrote: > > On Mon, 15 May 2006, Maxim Konovalov wrote: > > > There is a bug in raw ip code processing which panics system. I > > put a small regression test in > > src/tools/regression/netinet/rawconnect. > > > > At the moment the code path for the connected raw ip socket looks > > like that: > > > > % soclose() > > % sodisconnect() > > % rip_disconnect() > > % rip_abort() > > % rip_pcbdetach() > > % rip_detach <<<--------- panic > > % rip_pcbdetach() > > > > .. and we panics in rip_detach() at KASSERT(inp != NULL). > > > > With this patch panic has gone. > > This looks good in terms of pcb structure, but you should acquire > SOCK_LOCK around the so_state manipulation. To prevent races, I > suggest doing it while also holding the INP lock in the center of > the locking sets from the inpcb. There are some other remaining bugs > in the raw socket code elsewhere also, I think. I "copied" this code from udp_usrreq.c::udp_disconnect(). There is no such lock. Is it a bug too? -- Maxim Konovalov
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060521215823.H6324>