linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Stancek <jstancek@redhat.com>
To: Jeff Layton <jlayton@kernel.org>
Cc: linux-fsdevel@vger.kernel.org, ltp@lists.linux.it
Subject: Re: [bug?] mutual exclusion between posix and OFD locks
Date: Fri, 15 Jun 2018 09:30:46 -0400 (EDT)	[thread overview]
Message-ID: <401507445.26865582.1529069446371.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <1ce001a4909607e13da4c2fa7a87b814f0c0be4c.camel@kernel.org>



----- Original Message -----
> On Fri, 2018-06-15 at 13:11 +0200, Jan Stancek wrote:
> > Hi,
> > 
> > Attached is simplified reproducer (LTP fcntl36), where
> > 2 threads try to lock same region in a file. One is
> > using posix write lock, the other OFD read lock.
> > 
> > Observed problem: 2 threads obtain lock simultaneously.
> > 
> > --- strace excerpt ---
> > [pid 16853] 06:57:11 openat(AT_FDCWD, "tst_ofd_posix_locks", O_RDWR) = 3
> > [pid 16854] 06:57:11 openat(AT_FDCWD, "tst_ofd_posix_locks", O_RDWR) = 4
> > ...
> > [pid 16853] 06:57:12 fcntl(3, F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET,
> > l_start=0, l_len=4096} <unfinished ...>
> > [pid 16854] 06:57:12 fcntl(4, F_OFD_SETLKW, {l_type=F_RDLCK,
> > l_whence=SEEK_SET, l_start=0, l_len=4096} <unfinished ...>
> > [pid 16853] 06:57:12 <... fcntl resumed> ) = 0
> > [pid 16853] 06:57:12 nanosleep({tv_sec=0, tv_nsec=100000},  <unfinished
> > ...>
> > [pid 16854] 06:57:12 <... fcntl resumed> ) = 0
> > --- /strace excerpt ---
> > 
> > fcntl(2) says:
> >   Conflicting lock combinations (i.e., a read lock and a write
> >   lock or two write locks) where one lock is an open file
> >   description lock and the other is a traditional record lock
> >   conflict even when they are acquired by the same process on
> >   the same file descriptor.
> > 
> > Reproducible on x86_64 VM, with v4.17-11782-gbe779f03d563.
> > 
> > Thanks for having a look,
> > Jan
> > 
> 
> tl;dr: I think the test program is buggy. You're running afoul of one of
> the behaviors of traditional POSIX locks that caused us to add OFD locks
> in the first place. On any call to close() all traditional POSIX locks
> in the process are dropped.
> 
> Longer explanation: You have 3 thread pairs, and each one does a
> close(fd) at the end of the thread func. When you go to join the
> threads, it ends up calling close(fd), and that causes _all_ traditional
> POSIX locks to get released, even ones that might still be in use by
> other threads.
> 
> If you comment out the close(fd); calls in both thread funcs then the
> program seems to reliably run to completion.

Thanks Jeff. You're right, the problem goes away if I drop close().
I recall reading that part in man page, but this race eluded me.

Sorry for false alarm, we'll fix the test (fcntl36).

Regards,
Jan

> --
> Jeff Layton <jlayton@kernel.org>
> 

      reply	other threads:[~2018-06-15 13:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-15 11:11 [bug?] mutual exclusion between posix and OFD locks Jan Stancek
2018-06-15 13:20 ` Jeff Layton
2018-06-15 13:30   ` Jan Stancek [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=401507445.26865582.1529069446371.JavaMail.zimbra@redhat.com \
    --to=jstancek@redhat.com \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).