From owner-freebsd-hackers Tue Apr 20 13:11:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.tar.com (ns.tar.com [204.95.187.2]) by hub.freebsd.org (Postfix) with ESMTP id F032715815 for ; Tue, 20 Apr 1999 13:11:36 -0700 (PDT) (envelope-from dick@ns.tar.com) Received: (from dick@localhost) by ns.tar.com (8.9.3/8.9.3) id PAA35737; Tue, 20 Apr 1999 15:09:02 -0500 (CDT) (envelope-from dick) Date: Tue, 20 Apr 1999 15:09:02 -0500 From: "Richard Seaman, Jr." To: Luoqi Chen , John Plevyak Cc: hackers@FreeBSD.ORG Subject: Re: flock + kernel threads bug Message-ID: <19990420150902.A89750@tar.com> References: <199904201759.NAA15897@lor.watermarkgroup.com> <19990420111634.D10370@proxydev.inktomi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <19990420111634.D10370@proxydev.inktomi.com>; from John Plevyak on Tue, Apr 20, 1999 at 11:16:34AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Apr 20, 1999 at 11:16:34AM -0700, John Plevyak wrote: > > I sumbmitted a bug: kern/10265 it includes a description, > a program to repro and a patch. > > The problem is: > > releases of file locks depend on the close coming from the > same PID as took out the lock. Since kernel threads have > different PIDs it is possible for a peer thread to close > the file locked by another peer. This results in the file > lock not being cleared. > > The patch does: > > 1. to use p->p_leader as the PID for file locking, > 2. to use p->p_leader->p_flag & P_ADVLOCK to determine if locks are held > 3. ensure that p->p_leader does not complete exit1() before > all the peers. I think this patch is a reasonable kludge to solve a problem. However, it should be noted (perhaps even in a comment to the commit or in the code) that there is really a bigger issue here. That is that POSIX threads specs require "threads" to have the same PID as the "process" that spawns them. The current kernel structure in FreeBSD does not support this notion. Once consequence is that posix kernel threads in FreeBSD will have trouble being fully compliant, which affects at least signal handling and the priority functions, and probably others (in addition to the file locking issue raised here). Using p->p_leader to proxy for the idea that each thread should have the same PID as the process is helpful, but doesn't solve the problem completely. The better solution to this problem will come when/if there is better support for the distinction between "kernel threads" and "processes". -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message