Re: flock(2): locking against itself?

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sat, 18 Mar 2023 11:32:37 -0400 (EDT)
    From:        Mouse <mouse%Rodents-Montreal.ORG@localhost>
    Message-ID:  <202303181532.LAA29028%Stone.Rodents-Montreal.ORG@localhost>

  | On examination, the manpages available to me (including the one at
  | http://man.netbsd.org/flock.2) turn out to say nothing to clarify this.

The man page (including the one on the web that you referenced) starts out:

 flock() applies or removes an advisory lock on the file associated with
     the file descriptor fd.

and then lower down, under NOTES:

     Locks are on files, not file descriptors.  That is, file descriptors
     duplicated through dup(2) or fork(2) do not result in multiple instances
     of a lock, but rather multiple references to a single lock.  If a process
     holding a lock on a file forks and the child explicitly unlocks the file,
     the parent will lose its lock.

Applying flock() to an already locked (of this kernel file*) file
is an attempt to upgrade, or downgrade (including unlock) the file,
and would only block on an upgrade attempt if some other file*
referencing the same file (ie: the product of a distinct open() etc)
is holding a lock that blocks the upgrade.

  | Is this expected behaviour, or is it a bug?

Expected

Always been this way.

kre