From: "J. Bruce Fields" <bfields@fieldses.org>
To: Filipe Brandenburger <filbranden@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
Matthew Wilcox <matthew@wil.cx>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] locks: prevent side-effects of locks_release_private before file_lock is initialized
Date: Mon, 18 Jun 2012 16:01:31 -0400 [thread overview]
Message-ID: <20120618200131.GA12351@fieldses.org> (raw)
In-Reply-To: <1339815965-1171-2-git-send-email-filbranden@gmail.com>
On Fri, Jun 15, 2012 at 11:06:05PM -0400, Filipe Brandenburger wrote:
> When calling fcntl(F_SETLEASE) for a second time on the same fd, do_fcntl_add_lease
> will allocate and initialize a new file_lock, then if __vfs_setlease decides to
> reuse the existing file_lock it will free the newly allocated one to prevent leaking
> memory.
>
> However, the new file_lock was initialized to the point where it has a valid file
> descriptor pointer and lmops, so calling locks_free_lock will trigger a call to
> lease_release_private_callback which will have the side effect of clearing the
> fcntl(F_SETOWN) and fcntl(F_SETSIG) settings for the file descriptor even though
> that was not supposed to happen at that point.
>
> This patch will fix this by calling kmem_cache_free(filelock_cache, fl) instead of
> locks_free_lock(fl) if the file_lock is not completely initialized and actually
> associated to the file descriptor, avoiding the call to lease_release_private_callback
> with the undesired side effects.
Thanks for catching this!
The result doesn't feel entirely obvious to me. We could consolidate
the two kmem_cache_free calls and add a comment saying why we're not
calling locks_free_lock().
But clearest might be to separate allocation and initialization and
delay the latter till we know we're going to need it?
--b.
>
> Signed-off-by: Filipe Brandenburger <filbranden@gmail.com>
> ---
> fs/locks.c | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/fs/locks.c b/fs/locks.c
> index 814c51d..ce57c59 100644
> --- a/fs/locks.c
> +++ b/fs/locks.c
> @@ -473,7 +473,7 @@ static struct file_lock *lease_alloc(struct file *filp, int type)
>
> error = lease_init(filp, type, fl);
> if (error) {
> - locks_free_lock(fl);
> + kmem_cache_free(filelock_cache, fl);
> return ERR_PTR(error);
> }
> return fl;
> @@ -1538,7 +1538,7 @@ static int do_fcntl_add_lease(unsigned int fd, struct file *filp, long arg)
>
> new = fasync_alloc();
> if (!new) {
> - locks_free_lock(fl);
> + kmem_cache_free(filelock_cache, fl);
> return -ENOMEM;
> }
> ret = fl;
> @@ -1546,11 +1546,11 @@ static int do_fcntl_add_lease(unsigned int fd, struct file *filp, long arg)
> error = __vfs_setlease(filp, arg, &ret);
> if (error) {
> unlock_flocks();
> - locks_free_lock(fl);
> + kmem_cache_free(filelock_cache, fl);
> goto out_free_fasync;
> }
> if (ret != fl)
> - locks_free_lock(fl);
> + kmem_cache_free(filelock_cache, fl);
>
> /*
> * fasync_insert_entry() returns the old entry if any.
> --
> 1.7.7.6
>
next prev parent reply other threads:[~2012-06-18 20:01 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-16 3:06 [PATCH 0/1] locks: prevent side-effects of locks_release_private before file_lock is initialized Filipe Brandenburger
2012-06-16 3:06 ` [PATCH 1/1] " Filipe Brandenburger
2012-06-18 20:01 ` J. Bruce Fields [this message]
2012-06-20 2:39 ` Filipe Brandenburger
2012-06-26 0:29 ` J. Bruce Fields
2012-06-26 0:48 ` Filipe Brandenburger
2012-06-26 2:10 ` Filipe Brandenburger
2012-06-26 2:10 ` Filipe Brandenburger
2012-06-26 15:23 ` J. Bruce Fields
2012-06-27 1:50 ` [PATCH v2 " Filipe Brandenburger
2012-07-05 22:42 ` J. Bruce Fields
2012-07-07 19:04 ` J. Bruce Fields
2012-07-27 4:42 ` [PATCHv3] " Filipe Brandenburger
2012-07-27 20:45 ` J. Bruce Fields
2012-07-29 15:56 ` J. Bruce Fields
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=20120618200131.GA12351@fieldses.org \
--to=bfields@fieldses.org \
--cc=filbranden@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@wil.cx \
--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 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.