linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@poochiereds.net>
To: Benjamin Coddington <bcodding@redhat.com>,
	bfields@fieldses.org, Alexander Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] fs/locks: Use fs-specific l_pid for remote locks
Date: Wed, 07 Jun 2017 07:40:07 -0400	[thread overview]
Message-ID: <1496835607.3703.1.camel@poochiereds.net> (raw)
In-Reply-To: <f4908c50d34aed05a93f74302f1a6ce410ec9d15.1496781719.git.bcodding@redhat.com>

On Tue, 2017-06-06 at 16:45 -0400, Benjamin Coddington wrote:
> Now that we're translating fl_pid for F_GETLK and /proc/locks, we need to
> handle the case where a remote filesystem directly sets fl_pid.  In that
> case, the fl_pid should not be translated into a local pid namespace.  If
> the filesystem implements the lock operation, set a flag to return the
> lock's fl_pid value directly, rather translate it.
> 

Actually, you're not translating anything for F_GETLK until we get to
this patch. Patch #2 in this series removes the fl_nspid field, but the
pid translation isn't fixed until here. That does mean a nominal
regression here in how fl_pid is reported between the two.

Would it be best to squash #2 and #3 together? Or maybe just go ahead
and universally translate the fl_pid field until you add the flag in
this patch?

Also to make sure I understand: task->tgid will always represent the
task's pid in the init_pid_ns, right?

Other than the minor bisectability concern, I think this looks good.
Nice work!

> Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
> ---
>  fs/locks.c         | 22 ++++++++++++++++++----
>  include/linux/fs.h |  1 +
>  2 files changed, 19 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/locks.c b/fs/locks.c
> index 8d48e4c42ed3..206a46d28bbd 100644
> --- a/fs/locks.c
> +++ b/fs/locks.c
> @@ -2034,8 +2034,10 @@ SYSCALL_DEFINE2(flock, unsigned int, fd, unsigned int, cmd)
>   */
>  int vfs_test_lock(struct file *filp, struct file_lock *fl)
>  {
> -	if (filp->f_op->lock && is_remote_lock(filp))
> +	if (filp->f_op->lock && is_remote_lock(filp)) {
> +		fl->fl_flags |= FL_PID_PRIV;
>  		return filp->f_op->lock(filp, F_GETLK, fl);
> +	}
>  	posix_test_lock(filp, fl);
>  	return 0;
>  }
> @@ -2060,9 +2062,18 @@ static pid_t locks_translate_pid(int init_nr, struct pid_namespace *ns)
>  	return vnr;
>  }
>  
> +static pid_t flock_translate_pid(struct file_lock *fl)
> +{
> +	if (IS_OFDLCK(fl))
> +		return -1;
> +	if (fl->fl_flags & FL_PID_PRIV)
> +		return fl->fl_pid;
> +	return locks_translate_pid(fl->fl_pid,  task_active_pid_ns(current));
> +}
> +
>  static int posix_lock_to_flock(struct flock *flock, struct file_lock *fl)
>  {
> -	flock->l_pid = IS_OFDLCK(fl) ? -1 : fl->fl_pid;
> +	flock->l_pid = flock_translate_pid(fl);
>  #if BITS_PER_LONG == 32
>  	/*
>  	 * Make sure we can represent the posix lock via
> @@ -2084,7 +2095,7 @@ static int posix_lock_to_flock(struct flock *flock, struct file_lock *fl)
>  #if BITS_PER_LONG == 32
>  static void posix_lock_to_flock64(struct flock64 *flock, struct file_lock *fl)
>  {
> -	flock->l_pid = IS_OFDLCK(fl) ? -1 : fl->fl_pid;
> +	flock->l_pid = flock_translate_pid(fl);
>  	flock->l_start = fl->fl_start;
>  	flock->l_len = fl->fl_end == OFFSET_MAX ? 0 :
>  		fl->fl_end - fl->fl_start + 1;
> @@ -2598,7 +2609,10 @@ static void lock_get_status(struct seq_file *f, struct file_lock *fl,
>  	unsigned int fl_pid;
>  	struct pid_namespace *proc_pidns = file_inode(f->file)->i_sb->s_fs_info;
>  
> -	fl_pid = locks_translate_pid(fl->fl_pid, proc_pidns);
> +	if (fl->fl_flags & FL_PID_PRIV)
> +		fl_pid = fl->fl_pid;
> +	else
> +		fl_pid = locks_translate_pid(fl->fl_pid, proc_pidns);
>  	/*
>  	 * If there isn't a fl_pid don't display who is waiting on
>  	 * the lock if we are called from locks_show, or if we are
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index b013fac515f7..179496a9719d 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -908,6 +908,7 @@ static inline struct file *get_file(struct file *f)
>  #define FL_UNLOCK_PENDING	512 /* Lease is being broken */
>  #define FL_OFDLCK	1024	/* lock is "owned" by struct file */
>  #define FL_LAYOUT	2048	/* outstanding pNFS layout */
> +#define FL_PID_PRIV	4096	/* F_GETLK should report fl_pid */
>  
>  #define FL_CLOSE_POSIX (FL_POSIX | FL_CLOSE)
>  

-- 
Jeff Layton <jlayton@poochiereds.net>

  reply	other threads:[~2017-06-07 11:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-06 20:45 [PATCH 0/3 v4] Fixups for l_pid Benjamin Coddington
2017-06-06 20:45 ` [PATCH 1/3] fs/locks: Use allocation rather than the stack in fcntl_getlk() Benjamin Coddington
2017-06-06 20:45 ` [PATCH 2/3] fs/locks: Remove fl_nspid Benjamin Coddington
2017-06-06 20:45 ` [PATCH 3/3] fs/locks: Use fs-specific l_pid for remote locks Benjamin Coddington
2017-06-07 11:40   ` Jeff Layton [this message]
2017-06-19 12:37     ` Benjamin Coddington
2017-06-19 12:53       ` Benjamin Coddington
2017-06-07 11:50   ` Jeff Layton
  -- strict thread matches above, loose matches on Subject: below --
2017-06-06 17:19 [PATCH 0/3 v3] Fixups for l_pid Benjamin Coddington
2017-06-06 17:19 ` [PATCH 3/3] fs/locks: Use fs-specific l_pid for remote locks Benjamin Coddington

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=1496835607.3703.1.camel@poochiereds.net \
    --to=jlayton@poochiereds.net \
    --cc=bcodding@redhat.com \
    --cc=bfields@fieldses.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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).