From owner-freebsd-bugs Sat Jan 19 15:20:15 2002 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 8E12637B416 for ; Sat, 19 Jan 2002 15:20:03 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g0JNK3r86025; Sat, 19 Jan 2002 15:20:03 -0800 (PST) (envelope-from gnats) Date: Sat, 19 Jan 2002 15:20:03 -0800 (PST) Message-Id: <200201192320.g0JNK3r86025@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Ian Dowse Subject: Re: kern/8498: Race condition between unp_gc() and accept(). Reply-To: Ian Dowse Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR kern/8498; it has been noted by GNATS. From: Ian Dowse To: freebsd-gnats-submit@freebsd.org Cc: Subject: Re: kern/8498: Race condition between unp_gc() and accept(). Date: Sat, 19 Jan 2002 23:17:46 +0000 Adding to the audit trail: In message , Alexand er Viro writes: > > >On Sat, 19 Jan 2002 iedowse@FreeBSD.org wrote: > >> Synopsis: Race condition between unp_gc() and accept(). >> >> State-Changed-From-To: open->feedback >> State-Changed-By: iedowse >> State-Changed-When: Sat Jan 19 14:47:11 PST 2002 >> State-Changed-Why: >> >> Does this problem still exist? > >As far as I can see it's still there in HEAD - analysis from the original >bug report still applies. > >BTW, there is another problem: uipc_userreq.c:1378 has > extra_ref = malloc(nfiles * sizeof(struct file *), M_FILE, M_WAITOK); >which can block. During that time we might get new files opened and sent >in SCM_RIGHTS cookies. Notice that > a) we will have them _not_ marked, so the code after that will try >to kill them. > b) nfiles might have grown! > >The former means that legitimate stuff gets killed. The latter is a buffer >overrun in kernel space waiting to happen. > >Fix: invert the logics with "marked". I.e. start with marking everything, >then unmark those you want to stay around. Then by the end of the first >phase you have marked exactly the stuff that needs to die. New struct >file won't be marked, so the loop populating extra_ref will skip it... > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message