From: "Venkateswararao Jujjuri (JV)" <jvrao@linux.vnet.ibm.com>
To: Eric Van Hensbergen <ericvh@gmail.com>
Cc: v9fs-developer@lists.sourceforge.net, linux-fsdevel@vger.kernel.org
Subject: Re: [V9fs-developer] [PATCH] [fs/9p] Check for NULL fid pointers in p9_client_clunk()
Date: Tue, 24 Aug 2010 14:55:43 -0700 [thread overview]
Message-ID: <4C743FDF.4000502@linux.vnet.ibm.com> (raw)
In-Reply-To: <AANLkTimAV4sZx6tpkJH-YqBfgwysCaX2Vikbh7yt_bD8@mail.gmail.com>
Eric Van Hensbergen wrote:
> On Tue, Aug 24, 2010 at 10:43 AM, Venkateswararao Jujjuri (JV)
> <jvrao@linux.vnet.ibm.com> wrote:
>> NULL fid should be handled in cases where we endup calling v9fs_dir_release()
>> before even we instantiate the fid in filp. This patch handles
>> pasing a NULL p9_fid* to p9_client_clunk.
>>
>> Signed-off-by: Venkateswararao Jujjuri <jvrao@linux.vnet.ibm.com>
>> ---
>> fs/9p/vfs_dir.c | 3 ++-
>> net/9p/client.c | 3 +++
>> 2 files changed, 5 insertions(+), 1 deletions(-)
>>
>> diff --git a/fs/9p/vfs_dir.c b/fs/9p/vfs_dir.c
>> index 16c8a2a..5f08203 100644
>> --- a/fs/9p/vfs_dir.c
>> +++ b/fs/9p/vfs_dir.c
>> @@ -292,7 +292,8 @@ int v9fs_dir_release(struct inode *inode, struct file *filp)
>>
>> fid = filp->private_data;
>> P9_DPRINTK(P9_DEBUG_VFS,
>> - "inode: %p filp: %p fid: %d\n", inode, filp, fid->fid);
>> + "JV: inode: %p filp: %p fid: %d\n", inode, filp,
>> + fid ? fid->fid : -1);
>
> Did you really mean to insert a JV: debug label in there?
Oops!!
>
>> filemap_write_and_wait(inode->i_mapping);
>> p9_client_clunk(fid);
>> return 0;
>> diff --git a/net/9p/client.c b/net/9p/client.c
>> index dc6f2f2..9338fb3 100644
>> --- a/net/9p/client.c
>> +++ b/net/9p/client.c
>> @@ -1201,6 +1201,9 @@ int p9_client_clunk(struct p9_fid *fid)
>> struct p9_client *clnt;
>> struct p9_req_t *req;
>>
>> + if (!fid)
>> + return 0;
>> +
>>
>
> While this will solve the NULL pointer dereference, it will do so
> silently which may lead to us leaking fids/memory/resources/etc. If
> we were to do such a thing, I'd want warning messages. However, I
> wouldn't want warning messages in the generic, because now we have
> places we are calling p9_client_clunk from where we expect null fids
> to be valid.
>
> I'd suggest keeping the fid check in v9fs_dir_release to parameterize
> sending the clunk since we expect to sometimes not have a fid here,
> and then in a separate patch adding some code to p9_client_clunk which
> complains loudly any time it gets called with a NULL fid. Its unclear
> to me whether this should be a BUG() or just a warning, a warning
> would probably suffice as it'll help us track down such cases during
> testing without breaking users.
So basically you need a conditional call to p9_client_clunk() .
v9fs_dir_release()
{
...
if (fid)
p9_client_clunk();
}
Do you recall any cases where we end up calling clunk w/o a valid fid?
So .. may be we should go with BUG(!fid) in clunck code?
Thanks,
JV
>
> -eric
prev parent reply other threads:[~2010-08-24 21:55 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-24 15:43 [PATCH] [fs/9p] Check for NULL fid pointers in p9_client_clunk() Venkateswararao Jujjuri (JV)
2010-08-24 19:38 ` [V9fs-developer] " Eric Van Hensbergen
2010-08-24 21:55 ` Venkateswararao Jujjuri (JV) [this message]
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=4C743FDF.4000502@linux.vnet.ibm.com \
--to=jvrao@linux.vnet.ibm.com \
--cc=ericvh@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=v9fs-developer@lists.sourceforge.net \
/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).