mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Chris Wright <chrisw@osdl.org>
Cc: Andrew Morton <akpm@osdl.org>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Make POSIX locks compatible with the NPTL thread model
Date: Wed, 23 Jun 2004 19:02:07 -0400	[thread overview]
Message-ID: <1088031727.8944.71.camel@lade.trondhjem.org> (raw)
In-Reply-To: <20040623144150.H21045@build.pdx.osdl.net>

På on , 23/06/2004 klokka 17:41, skreiv Chris Wright:

> Yes, it's a BUG in locks_remove_flock.  The first patch changes
> locks_remove_posix, so posix lock is missed on filp_close and the BUG
> is hit.  I believe the problem is that locks can have same fl_owner,
> w/out having same tgid.

Yep. I agree with that analysis. Blech...

That just goes to show how broken the posix locks "logic" is when
applied to CLONE_FILES: POSIX locks are not supposed to be inherited by
child processes, and so the current VFS code checks both lock->fl_pid &
lock->fl_owner in tests such as posix_locks_conflict(). Currently (as I
said) on filp_close() we remove all locks with the same lock->fl_owner
without checking the pid.

However upon the last fput(), then in practice locks_remove_flock()
expects all locks with the same *file descriptor* to have been cleaned
up.

So what do we do? There is no way that we can keep the current rules, as
they provide no consistent way to inform the underlying NFS or CIFS
filesystem  when to test for lock->fl_pid, when to test for
lock->fl_owner, and when to test for lock->fl_file.

Cheers,
  Trond

  reply	other threads:[~2004-06-23 23:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-23 17:07 Trond Myklebust
2004-06-23 19:29 ` Chris Wright
2004-06-23 19:50   ` Trond Myklebust
2004-06-23 21:41     ` Chris Wright
2004-06-23 23:02       ` Trond Myklebust [this message]
2004-06-24  6:09         ` Chris Wright
2004-06-24 11:56 ` Andreas Gruenbacher
2004-06-24 21:06   ` Trond Myklebust

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=1088031727.8944.71.camel@lade.trondhjem.org \
    --to=trond.myklebust@fys.uio.no \
    --cc=akpm@osdl.org \
    --cc=chrisw@osdl.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®