From: Al Viro <viro@ZenIV.linux.org.uk>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-fsdevel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] vfs: Don't leak a path when get_empty_filp in dentry_open
Date: Thu, 16 Jan 2014 23:59:25 +0000 [thread overview]
Message-ID: <20140116235925.GY10323@ZenIV.linux.org.uk> (raw)
In-Reply-To: <871u07wkwt.fsf@xmission.com>
On Thu, Jan 16, 2014 at 03:45:38PM -0800, Eric W. Biederman wrote:
>
> Normally in dentry_open the passed in path is placed on the new filp
> removing the caller from needing to worry about it. In the rare case
> that we can not allocate a filp the path is not consumed. None of the
> callers of dentry_open call path_put in their error handling when
> dentry_open fails so call path_put for them on error and keep everyone's
> error handling simple.
You are misreading that code. _No_ path in dentry_open() drops that
sucker, no matter whether we succeed or fail. do_dentry_open() grabs
an extra reference on success, so those fput() on other failure exits
just balance that.
The calling conventions are not "transfer the reference you held into
struct file, caller must drop on failure"; it's "clone the reference
into struct file; caller's reference remains in all cases".
IOW, you are looking for path_put() in error handling in callers, when
in fact it's on common paths (and quite often in callers of callers of
callers). Makes life simpler, actually. Try to convert it to your
variant of calling conventions and you'll see that callers become more
complex and brittle. As it is, this patch is simply broken - you'll get
double path_put() out of it, not to mention the different treatment of
refcounts depending on the kind of failure exit that had been taken.
NAK.
next prev parent reply other threads:[~2014-01-16 23:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-16 23:45 [PATCH] vfs: Don't leak a path when get_empty_filp in dentry_open Eric W. Biederman
2014-01-16 23:59 ` Al Viro [this message]
2014-01-17 0:17 ` Eric W. Biederman
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=20140116235925.GY10323@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--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