linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: stsp <stsp2@yandex.ru>, linux-kernel@vger.kernel.org
Cc: Chuck Lever <chuck.lever@oracle.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Christian Brauner <brauner@kernel.org>,
	linux-fsdevel@vger.kernel.org,
	Matthew Wilcox <willy@infradead.org>
Subject: Re: [PATCH 2/3] fd/locks: allow get the lock owner by F_OFD_GETLK
Date: Wed, 21 Jun 2023 06:35:21 -0400	[thread overview]
Message-ID: <26dce201000d32fd3ca1ca5b5f8cd4f5ae0b38b2.camel@kernel.org> (raw)
In-Reply-To: <9c0a7cde-da32-bc09-0724-5b1387909d18@yandex.ru>

On Wed, 2023-06-21 at 11:57 +0500, stsp wrote:
> 20.06.2023 18:58, Jeff Layton пишет:
> > No, it won't. The l_pid field is populated from the file_lock->fl_pid.
> > That field is set when the lock is set, and never updated. So it's quite
> > possible for F_GETLK to return the pid of a process that no longer
> > exists.
> > 
> > In principle, we could try to address that by changing how we track lock
> > ownership, but that's a fairly major overhaul, and I'm not clear on any
> > use-cases where that matters.
> 
> OK, in this case I'll just put a comments
> into the code, summarizing the info I got
> from you and Matthew.
> Thanks guys for all the info, its very helpful.
> 
> Now I only need to convert the current
> "fundamental problem" attitude into a "not
> implemented yet" via the code comment.
> 
> 
> > > So my call is to be brave and just re-consider
> > > the conclusion of that article, made 10 years
> > > ago! :)
> > > 
> > I think my foot has too many bullet wounds for that sort of bravery.
> I am perfectly fine with leaving this thing
> unimplemented. But what really bothers
> me is the posix proposal, which I think was
> done. Please tell me it allows fixing fl_pid
> in the future (rather than to mandate -1),
> and I am calm.

I don't think we can change this at this point.

The bottom line (again) is that OFD locks are owned by the file
descriptor (much like with flock()), and since file descriptors can be
shared across multiple process it's impossible to say that some single
process owns it.
-- 
Jeff Layton <jlayton@kernel.org>

  reply	other threads:[~2023-06-21 10:37 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-20  9:55 [PATCH 0/3] RFC: F_OFD_GETLK should provide more info Stas Sergeev
2023-06-20  9:55 ` [PATCH 1/3] fs/locks: F_UNLCK extension for F_OFD_GETLK Stas Sergeev
2023-06-20 10:46   ` Jeff Layton
2023-06-20 11:00     ` stsp
2023-06-20 11:15       ` Jeff Layton
2023-06-21 15:24         ` stsp
2023-06-20  9:55 ` [PATCH 2/3] fd/locks: allow get the lock owner by F_OFD_GETLK Stas Sergeev
2023-06-20 10:51   ` Jeff Layton
2023-06-20 10:57     ` stsp
2023-06-20 11:12       ` Jeff Layton
2023-06-20 11:45         ` stsp
2023-06-20 12:02           ` Jeff Layton
2023-06-20 12:34             ` stsp
2023-06-20 13:19               ` Jeff Layton
2023-06-20 13:39                 ` stsp
2023-06-20 13:46                   ` Matthew Wilcox
2023-06-20 13:47                     ` stsp
2023-06-20 14:36                       ` Matthew Wilcox
2023-06-20 15:45                         ` stsp
2023-06-20 17:05                           ` Matthew Wilcox
2023-06-21  2:54                             ` stsp
2023-06-23 13:10                     ` David Laight
2023-06-20 13:58                   ` Jeff Layton
2023-06-21  6:57                     ` stsp
2023-06-21 10:35                       ` Jeff Layton [this message]
2023-06-21 10:42                         ` stsp
2023-06-21 11:05                           ` Jeff Layton
2023-06-21 11:22                             ` stsp
2023-06-21 11:26                               ` stsp
2023-06-23 15:25                             ` Christian Brauner
2023-06-23 17:18                               ` stsp
2023-06-27 16:00                                 ` Jeff Layton
2023-06-27 16:20                                   ` stsp
2023-06-20  9:55 ` [PATCH 3/3] selftests: add OFD lock tests Stas Sergeev
2023-06-20 11:06   ` Jeff Layton

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=26dce201000d32fd3ca1ca5b5f8cd4f5ae0b38b2.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=brauner@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stsp2@yandex.ru \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.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;
as well as URLs for NNTP newsgroup(s).