From: Eric Van Hensbergen <ericvh@gmail.com>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org,
v9fs-developer@lists.sourceforge.net,
Linux FS Devel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH]: v9fs: add readpage support
Date: Fri, 13 Jan 2006 15:45:44 -0600 [thread overview]
Message-ID: <a4e6962a0601131345x6bf4ef3ftf3e6c6fb7bb2b530@mail.gmail.com> (raw)
In-Reply-To: <20060111033821.4b3d4d7b.akpm@osdl.org>
On 1/11/06, Andrew Morton <akpm@osdl.org> wrote:
> ericvh@gmail.com (Eric Van Hensbergen) wrote:
> > +
> > + result = v9fs_t_read(v9ses, fid, offset, rsize, &fcall);
> > +
> > + if (result < 0) {
> > + printk(KERN_ERR "v9fs_t_read returned %d\n",
> > + result);
> > +
> > + kfree(fcall);
> > + goto UnmapAndUnlock;
> > + } else
> > + offset += result;
> > +
> > + memcpy(buffer, fcall->params.rread.data, result);
> > +
> > + count -= result;
> > + buffer += result;
> > + total += result;
> > +
> > + kfree(fcall);
>
> Minor thing: from my reading of v9fs_mux_rpc() there's potential for a
> double-kfree here. Either v9fs_mux_rpc() needs to be changed to
> unambiguously zero out *rcall (or, better, v9fs_t_read does it) or you need
> to zero fcall on each go around the loop.
>
>
Okay, I had a chance to go back and look into this deeper when applied
on top of Lucho's new mux code. It appears (to Lucho and I) that the
the v9fs_mux_rpc() code zero's out *rcall really early on, so I don't
see where this could lead to a double kfree. If you still think we
are missing something, let me know and I'll have another look.
> > diff --git a/fs/9p/vfs_file.c b/fs/9p/vfs_file.c
> > index 6852f0e..feddc5c 100644
> > --- a/fs/9p/vfs_file.c
> > +++ b/fs/9p/vfs_file.c
> > @@ -289,6 +289,8 @@ v9fs_file_write(struct file *filp, const
> > total += result;
> > } while (count);
> >
> > + invalidate_inode_pages2(inode->i_mapping);
> > +
> > return total;
> > }
>
I went looking for an example of how to do this better. More or less,
v9fs reads and writes are similar to DirectIO since they don't go
through the page-cache. So, I looked at what NFS does when it gets a
DirectIO write, and it looks (to me) like it does more or less the
same thing:
(from nfs_file_direct_write() in fs/nfs/direct.c)
retval = nfs_direct_write(inode, ctx, &iov, pos, 1);
if (mapping->nrpages)
invalidate_inode_pages2(mapping);
Now, that being said, it still seems to me to be a bit heavy weight --
do folks have a better pointer to code that I can use as an example of
how to do this more efficiently?
-eric
next prev parent reply other threads:[~2006-01-13 21:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-11 1:14 [PATCH]: v9fs: add readpage support Eric Van Hensbergen
2006-01-11 11:38 ` Andrew Morton
2006-01-11 13:05 ` Eric Van Hensbergen
2006-01-13 21:45 ` Eric Van Hensbergen [this message]
2006-01-13 22:14 ` Andrew Morton
2006-01-13 22:27 ` Eric Van Hensbergen
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=a4e6962a0601131345x6bf4ef3ftf3e6c6fb7bb2b530@mail.gmail.com \
--to=ericvh@gmail.com \
--cc=akpm@osdl.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@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