From nobody@FreeBSD.org  Thu Dec  7 04:28:36 2000
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id 1734237B400
	for <freebsd-gnats-submit@FreeBSD.org>; Thu,  7 Dec 2000 04:28:36 -0800 (PST)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.1/8.11.1) id eB7CSZI37516;
	Thu, 7 Dec 2000 04:28:35 -0800 (PST)
	(envelope-from nobody)
Message-Id: <200012071228.eB7CSZI37516@freefall.freebsd.org>
Date: Thu, 7 Dec 2000 04:28:35 -0800 (PST)
From: simon@comsys.ntu-kpi.kiev.ua
Sender: nobody@FreeBSD.org
To: freebsd-gnats-submit@FreeBSD.org
Subject: fcntl(F_GETLK) return l_pid equal to -1 for the file loked with flock()
X-Send-Pr-Version: www-1.0

>Number:         23353
>Category:       docs
>Synopsis:       fcntl(F_GETLK) return l_pid equal to -1 for the file loked with flock()
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    maxim
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Dec 07 04:30:01 PST 2000
>Closed-Date:    Sun Mar 17 01:13:27 PST 2002
>Last-Modified:  Sun Mar 17 01:13:27 PST 2002
>Originator:     Andrey Simonenko
>Release:        4.1-STABLE i386
>Organization:
>Environment:
>Description:
If file is locked with flock() function and when I try to use fcntl(F_GETLK) function then it returns flock structure with following fileds:

l_type != F_UNLCK
l_pid == -1

if l_type isn't equal to F_UNLCK then I suppose that file is locked, but l_pid is always equal to -1.

From the fcnlt(2) manual page:

Note that flock(2) and fcntl(2) locks may be safely used concurrently.

That's why I think that it is a bug in flock() or fcntl() implementation.
>How-To-Repeat:

>Fix:


>Release-Note:
>Audit-Trail:

From: Maxim Konovalov <maxim@macomnet.ru>
To: freebsd-gnats-submit@FreeBSD.org
Cc: simon@comsys.ntu-kpi.kiev.ua
Subject: Re: kern/23353: fcntl(F_GETLK) return l_pid equal to -1 for the file
 loked with flock()
Date: Wed, 7 Nov 2001 16:30:43 +0300 (MSK)

 Hello,
 
 This behaviour is expected and it is not a bug. From "The Design and
 Implementation of the 4.4BSD Operating System" by Marshall Kirk
 McKusick et al, p.210:
 
 "The kernel handles the other differing semantics between the two
 implementations by having the byte-range locks be applied to processes
 whereas the whole-file locks are applied to descriptors. Because
 descriptors are shared with child processes, the whole-file locks are
 inherited. Because the child process gets its own process structure,
 the byte-fange locks are not inherited"
 
 Also take a look at /sys/kern/kern_descrip.c line 366 and line 1425.
 Flock(2) and fcntl(2) use different structures for lock
 identification.
 
 Imho the PR can be closed.
 
 - -maxim
 
 -- 
 Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer
 phone: +7 (095) 796-9079, mailto: maxim@macomnet.ru
 
 
State-Changed-From-To: open->feedback 
State-Changed-By: iedowse 
State-Changed-When: Sun Nov 18 07:58:16 PST 2001 
State-Changed-Why:  

Can this be closed? In the audit-trail it is suggested that this is 
expected behaviour. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=23353 

From: Maxim Konovalov <maxim@macomnet.ru>
To: Andrey Simonenko <simon@simon.org.ua>
Cc: iedowse@freebsd.org, <freebsd-bugs@freebsd.org>
Subject: Re: kern/23353: fcntl(F_GETLK) return l_pid equal to -1 for the file
 loked with flock()
Date: Mon, 19 Nov 2001 12:21:56 +0300 (MSK)

 Hello,
 
 On Sun, 18 Nov 2001, Andrey Simonenko wrote:
 
 > On Sun, 18 Nov 2001 iedowse@FreeBSD.org wrote:
 >
 [...]
 > > Can this be closed? In the audit-trail it is suggested that this is
 > > expected behaviour.
 > >
 >
 > May be my bug report isn't really a bug, but a message from Maxim didn't
 > make me think so. I know that in one case locks are inhereted by childs,
 > and in other case they aren't. The original my bug report was about
 > another thing. In the fcntl(2) manual page we can read that: "Note that
 > flock(2) and fcntl(2) locks can be safely used concurrently". And this
 > works. And if I locked some file with flock(2), then fcntl(F_GETLK) call
 > in some another process can tell me that that file is locked. But l_pid
 > field in the flock structure always is equal to -1 if file is locked with
 
 OK, just imagine a process got a lock by flock(2) and then fork(2)ed
 nine children, so we have ten processes with the same lock. What do
 you expect to find in flock.l_pid now? Imho l_pid is about clueless
 here because of the lock inheritance.
 
 Historically, flock(2) is a BSD interface and fcntl(F_???LK) is a
 POSIX one. They can be used concurrently for locking but there is a
 feature which I described above. Take a look at the line 517
 kern_lockf.c (1.25):
 
 if (block->lf_flags & F_POSIX)
 	fl->l_pid = ((struct proc *)(block->lf_id))->p_pid;
 else
 	fl->l_pid = -1;
 
 > flock(2) call (at least in my experiments). Also I haven't find any
 > information about this in manual pages.
 
 Agree.
 
 What about this patch for fcntl.2:
 
 Index: fcntl.2
 ===================================================================
 RCS file: /vol0/cvs/ncvs/src/lib/libc/sys/fcntl.2,v
 retrieving revision 1.35
 diff -u -r1.35 fcntl.2
 --- fcntl.2     2001/10/26 17:38:20     1.35
 +++ fcntl.2     2001/11/19 09:18:09
 @@ -535,6 +535,12 @@
  .Xr sigvec 2 ,
  .Xr tcgetpgrp 3 ,
  .Xr tcsetpgrp 3
 +.Sh BUGS
 +fcntl(F_GETLK) returns -1 in
 +.Fa l_pid
 +if the process holding a blocking lock previously locked the
 +file desriptor by
 +.Xr flock 2 .
  .Sh HISTORY
  The
  .Fn fcntl
 
 - -maxim
 
 -- 
 Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer
 phone: +7 (095) 796-9079, mailto: maxim@macomnet.ru
 
 
 
 

From: Maxim Konovalov <maxim@macomnet.ru>
To: freebsd-gnats-submit@freebsd.org
Cc:  
Subject: Re: kern/23353: fcntl(F_GETLK) return l_pid equal to -1 for the file
 loked with flock()
Date: Mon, 19 Nov 2001 14:42:57 +0300 (MSK)

 ---------- Forwarded message ----------
 Date: Mon, 19 Nov 2001 12:41:20 +0200 (EET)
 From: Andrey Simonenko <simon@simon.org.ua>
 To: Maxim Konovalov <maxim@macomnet.ru>
 Cc: iedowse@freebsd.org, freebsd-bugs@freebsd.org
 Subject: Re: kern/23353: fcntl(F_GETLK) return l_pid equal to -1 for the
     file loked with flock()
 
 
 On Mon, 19 Nov 2001, Maxim Konovalov wrote:
 
 > OK, just imagine a process got a lock by flock(2) and then fork(2)ed
 > nine children, so we have ten processes with the same lock. What do
 > you expect to find in flock.l_pid now? Imho l_pid is about clueless
 > here because of the lock inheritance.
 
 Probably l_pid should be equal to the PID of the parent and then, when
 the parent is terminated, it should be equal to one of its childs, and
 so on.
 
 >
 > Historically, flock(2) is a BSD interface and fcntl(F_???LK) is a
 > POSIX one. They can be used concurrently for locking but there is a
 > feature which I described above. Take a look at the line 517
 > kern_lockf.c (1.25):
 >
 > if (block->lf_flags & F_POSIX)
 > 	fl->l_pid = ((struct proc *)(block->lf_id))->p_pid;
 > else
 > 	fl->l_pid = -1;
 >
 
 Thanks, I understood.
 
 > > flock(2) call (at least in my experiments). Also I haven't find any
 > > information about this in manual pages.
 >
 > Agree.
 >
 > What about this patch for fcntl.2:
 >
 > Index: fcntl.2
 > ===================================================================
 > RCS file: /vol0/cvs/ncvs/src/lib/libc/sys/fcntl.2,v
 > retrieving revision 1.35
 > diff -u -r1.35 fcntl.2
 > --- fcntl.2     2001/10/26 17:38:20     1.35
 > +++ fcntl.2     2001/11/19 09:18:09
 > @@ -535,6 +535,12 @@
 >  .Xr sigvec 2 ,
 >  .Xr tcgetpgrp 3 ,
 >  .Xr tcsetpgrp 3
 > +.Sh BUGS
 > +fcntl(F_GETLK) returns -1 in
 > +.Fa l_pid
 > +if the process holding a blocking lock previously locked the
 > +file desriptor by
 > +.Xr flock 2 .
 >  .Sh HISTORY
 >  The
 >  .Fn fcntl
 >
 
 May be it will be good to put description of such behaviour of flock
 and fcntl to the manual page, not sure that it should be placed in
 the BUG section, but commiters should know where to put this sentence.
 
 In any way I agree that this PR can be closed.
 
 
 
State-Changed-From-To: feedback->closed 
State-Changed-By: ashp 
State-Changed-When: Fri Feb 8 21:49:41 PST 2002 
State-Changed-Why:  
Everyone agrees that this PR can be closed now. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=23353 
State-Changed-From-To: closed->open 
State-Changed-By: maxim 
State-Changed-When: Thu Mar 14 02:42:48 PST 2002 
State-Changed-Why:  
Still an issue. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=23353 
State-Changed-From-To: open->feedback 
State-Changed-By: maxim 
State-Changed-When: Thu Mar 14 03:05:30 PST 2002 
State-Changed-Why:  
Fixed in -current, lib/libc/sys/fcntl.2, rev. 1.36. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=23353 
Responsible-Changed-From-To: freebsd-bugs->maxim 
Responsible-Changed-By: maxim 
Responsible-Changed-When: Thu Mar 14 03:07:18 PST 2002 
Responsible-Changed-Why:  
I will MFC the patch. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=23353 
State-Changed-From-To: feedback->closed 
State-Changed-By: maxim 
State-Changed-When: Sun Mar 17 01:09:30 PST 2002 
State-Changed-Why:  
The behaviour has been documented in lib/libc/sys/fcntl.2 rev. 1.36 and 
rev. 1.16.2.10 in -current and -stable. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=23353 
>Unformatted:
