From owner-freebsd-current@FreeBSD.ORG Sun May 21 18:03:27 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BE3C16A654; Sun, 21 May 2006 18:03:27 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6E2C43D80; Sun, 21 May 2006 18:03:15 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.13.4/8.13.3) with ESMTP id k4LI3EMm008925; Sun, 21 May 2006 22:03:14 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Sun, 21 May 2006 22:03:14 +0400 (MSD) From: Maxim Konovalov To: Robert Watson In-Reply-To: <20060521185034.K8068@fledge.watson.org> Message-ID: <20060521215823.H6324@mp2.macomnet.net> 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: current@FreeBSD.org Subject: Re: HEADS UP: socket and pcb reference changes entering tree today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 May 2006 18:03:33 -0000 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