All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Jeff Layton <jlayton@redhat.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	nfs-ganesha-devel@lists.sourceforge.net,
	samba-technical@lists.samba.org
Subject: Re: [RFC PATCH v2 3/5] locks: add new "private" lock type that is owned by the filp
Date: Wed, 20 Nov 2013 14:50:32 -0500	[thread overview]
Message-ID: <20131120195032.GA7387@fieldses.org> (raw)
In-Reply-To: <1384965906-27327-4-git-send-email-jlayton@redhat.com>

On Wed, Nov 20, 2013 at 11:45:04AM -0500, Jeff Layton wrote:
> Due to some unfortunate history, POSIX locks have very strange and
> unhelpful semantics. The thing that usually catches people by surprise
> is that they are dropped whenever the process closes any file descriptor
> associated with the inode.
> 
> This is extremely problematic for people developing file servers that
> need to implement byte-range locks. Developers often need a "lock
> management" facility to ensure that file descriptors are not closed
> until all of the locks associated with the inode are finished.
> 
> This patchset adds a new type of lock that attempts to address this
> issue. These locks work just like "normal" POSIX read/write locks, but
> have semantics that are more like BSD locks with respect to inheritance
> and behavior on close.
> 
> This is implemented primarily by changing how fl_owner field is set for
> these locks. Instead of having them owned by the files_struct of the
> process, they are instead owned by the filp on which they were acquired.
> Thus, they are inherited across fork() and are only released when the
> last reference to a filp is put.
> 
> These new semantics prevent them from being merged with "classic" POSIX
> locks, even if they are acquired by the same process. These locks will
> also conflict with "classic" POSIX locks even if they are acquired by
> the same process or on the same file descriptor.
> 
> Signed-off-by: Jeff Layton <jlayton@redhat.com>
> ---
>  fs/locks.c                       | 22 +++++++++++++++++++++-
>  include/uapi/asm-generic/fcntl.h | 15 +++++++++++++++
>  2 files changed, 36 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/locks.c b/fs/locks.c
> index 86cafc3..3b278a6 100644
> --- a/fs/locks.c
> +++ b/fs/locks.c
> @@ -348,6 +348,26 @@ static int posix_assign_type(struct file_lock *fl, long type)
>  {
>  	int err;
>  
> +	/*
> +	 * FL_FILP_PRIVATE locks are "owned" by the filp upon which they were
> +	 * acquired, regardless of what task is dealing with them. Set the
> +	 * fl_owner appropriately.
> +	 */
> +	switch (type) {
> +	case F_RDLCKP:
> +		type = F_RDLCK;
> +		fl->fl_owner = (fl_owner_t)fl->fl_file;
> +		break;
> +	case F_WRLCKP:
> +		type = F_WRLCK;
> +		fl->fl_owner = (fl_owner_t)fl->fl_file;
> +		break;
> +	case F_UNLCKP:
> +		type = F_UNLCK;
> +		fl->fl_owner = (fl_owner_t)fl->fl_file;
> +		break;
> +	}
> +

After this fl_owner gets set to current->files in
flock{64}_to_posix_lock and then reset here.  That seems like a trap for
the unwary reader.

Could you do something like rename this flock_to_posix_lock_common and
move all the 32/64-bit-independent initialization here?

Looks like there's way more duplication than necessary between those two
cases.

(Also, why do we have an fl_owner_t instead of using a void?)

--b.

>  	err = assign_type(fl, type);
>  	if (err)
>  		return err;
> @@ -2225,7 +2245,7 @@ void locks_remove_filp(struct file *filp)
>  
>  	while ((fl = *before) != NULL) {
>  		if (fl->fl_file == filp) {
> -			if (IS_FLOCK(fl)) {
> +			if (IS_FLOCK(fl) || IS_POSIX(fl)) {
>  				locks_delete_lock(before);
>  				continue;
>  			}
> diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h
> index 95e46c8..6b7b68a 100644
> --- a/include/uapi/asm-generic/fcntl.h
> +++ b/include/uapi/asm-generic/fcntl.h
> @@ -151,6 +151,21 @@ struct f_owner_ex {
>  #define F_UNLCK		2
>  #endif
>  
> +/*
> + * fd "private" POSIX locks.
> + *
> + * Usually POSIX locks held by a process are released on *any* close and are
> + * not inherited across a fork().
> + *
> + * These lock types will conflict with normal POSIX locks, but are "owned"
> + * by the fd, not the process. This means that they are inherited across
> + * fork() like BSD (flock) locks, and they are only closed when the last
> + * reference to the the filp against which were acquired is closed.
> + */
> +#define F_RDLCKP	5
> +#define F_WRLCKP	6
> +#define F_UNLCKP	7
> +
>  /* for old implementation of bsd flock () */
>  #ifndef F_EXLCK
>  #define F_EXLCK		4	/* or 3 */
> -- 
> 1.8.3.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2013-11-20 19:50 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-20 16:45 [RFC PATCH v2 0/5] locks: implement "filp-private" (aka UNPOSIX) locks Jeff Layton
2013-11-20 16:45 ` [RFC PATCH v2 1/5] locks: consolidate checks for compatible filp->f_mode values in setlk handlers Jeff Layton
2013-11-20 16:45   ` Jeff Layton
2013-11-21 17:35   ` Christoph Hellwig
2013-11-20 16:45 ` [RFC PATCH v2 2/5] locks: rename locks_remove_flock to locks_remove_filp Jeff Layton
2013-11-21 17:35   ` Christoph Hellwig
2013-11-20 16:45 ` [RFC PATCH v2 3/5] locks: add new "private" lock type that is owned by the filp Jeff Layton
2013-11-20 16:45   ` Jeff Layton
2013-11-20 19:50   ` J. Bruce Fields [this message]
2013-11-20 20:00     ` Jeff Layton
2013-11-20 20:00       ` Jeff Layton
2013-12-09 16:46     ` [Nfs-ganesha-devel] " Jeff Layton
2013-12-10 20:35       ` J. Bruce Fields
2013-11-21 17:36   ` Christoph Hellwig
2013-11-20 16:45 ` [RFC PATCH v2 4/5] locks: show private lock types in /proc/locks Jeff Layton
2013-11-20 20:00   ` J. Bruce Fields
2013-11-20 20:03     ` Jeff Layton
2013-11-20 20:03       ` Jeff Layton
2013-11-20 20:04     ` J. Bruce Fields
2013-11-20 16:45 ` [RFC PATCH v2 5/5] locks: report l_pid as -1 for FL_FILP_PRIVATE locks Jeff Layton
2013-11-20 17:55   ` Frank Filz
2013-11-20 17:55     ` Frank Filz
2013-11-20 18:57     ` Jeff Layton
2013-11-20 18:57       ` 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=20131120195032.GA7387@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=jlayton@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nfs-ganesha-devel@lists.sourceforge.net \
    --cc=samba-technical@lists.samba.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.