From: Neil Brown <neilb@suse.de>
To: Valerie Aurora <vaurora@redhat.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Christoph Hellwig <hch@infradead.org>,
Jan Blunck <jblunck@suse.de>,
David Woodhouse <dwmw2@infradead.org>,
linux-nfs@vger.kernel.org,
"J. Bruce Fields" <bfields@fieldses.org>
Subject: Re: [PATCH 05/39] whiteout/NFSD: Don't return information about whiteouts to userspace
Date: Fri, 7 May 2010 07:18:08 +1000 [thread overview]
Message-ID: <20100507071808.20028458@notabene.brown> (raw)
In-Reply-To: <20100506180151.GA21062@shell>
On Thu, 6 May 2010 14:01:51 -0400
Valerie Aurora <vaurora@redhat.com> wrote:
> On Tue, May 04, 2010 at 09:37:31AM +1000, Neil Brown wrote:
> > On Mon, 3 May 2010 16:12:04 -0700
> > Valerie Aurora <vaurora@redhat.com> wrote:
> >
> > > From: Jan Blunck <jblunck@suse.de>
> > >
> > > Userspace isn't ready for handling another file type, so silently drop
> > > whiteout directory entries before they leave the kernel.
> >
> > Feels very intrusive doesn't it....
> >
> > Have you considered something like the following?
>
> Hrm, I see how that could be more elegant, but I'd rather avoid yet
> another layer of function pointer passing around. This code is
> already hard enough to review...
Yes, the extra indirection is a bit of a negative, but I don't think this
patch is harder to review than the alternate.
From a numerical perspective, with this patch you only need to look at the
various places that ->readdir is called to be sure it is always correct.
There are about 3. With the original you need to look at ever filldir
function. Jan has found 9.
And from a maintainability perspective, I think my approach is safer. Given
that there are 9 filldir functions already, the chance that a need will be
found for another seems good, and the chance that the coder will know to
check for DT_WHT is a best even. Conversely if another call to ->readdir
were added it is likely that nothing would need to be done.
Of course just counting things doesn't give a completely picture but I think
it can be indicative.
NeilBrown
>
> -VAL
>
> > NeilBrown
> >
> > diff --git a/fs/readdir.c b/fs/readdir.c
> > index 7723401..4c5b347 100644
> > --- a/fs/readdir.c
> > +++ b/fs/readdir.c
> > @@ -19,10 +19,26 @@
> >
> > #include <asm/uaccess.h>
> >
> > +struct readdir_info {
> > + filldir_t filler;
> > + void *data;
> > +};
> > +
> > +static int white_out(void *vrdi, const char *name, int namlen,
> > + loff_t offset, u64 ino, unsigned int d_type)
> > +{
> > + struct readdir_info *rdi = vrdi;
> > + if (d_type == DT_WHT)
> > + return 0;
> > + return rdi->filler(rdi->data, name, namlen, offset, info, d_type);
> > +}
> > +
> > int vfs_readdir(struct file *file, filldir_t filler, void *buf)
> > {
> > struct inode *inode = file->f_path.dentry->d_inode;
> > int res = -ENOTDIR;
> > + struct readir_info rdi = { filler, buf };
> > +
> > if (!file->f_op || !file->f_op->readdir)
> > goto out;
> >
> > @@ -36,7 +52,7 @@ int vfs_readdir(struct file *file, filldir_t filler, void *buf)
> >
> > res = -ENOENT;
> > if (!IS_DEADDIR(inode)) {
> > - res = file->f_op->readdir(file, buf, filler);
> > + res = file->f_op->readdir(file, &rdi, white_out);
> > file_accessed(file);
> > }
> > mutex_unlock(&inode->i_mutex);
next prev parent reply other threads:[~2010-05-06 21:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1272928358-20854-1-git-send-email-vaurora@redhat.com>
2010-05-03 23:12 ` [PATCH 05/39] whiteout/NFSD: Don't return information about whiteouts to userspace Valerie Aurora
2010-05-03 23:37 ` Neil Brown
2010-05-06 18:01 ` Valerie Aurora
2010-05-06 21:18 ` Neil Brown [this message]
2010-05-17 19:51 ` Valerie Aurora
[not found] <1281282776-5447-1-git-send-email-vaurora@redhat.com>
2010-08-08 15:52 ` Valerie Aurora
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=20100507071808.20028458@notabene.brown \
--to=neilb@suse.de \
--cc=bfields@fieldses.org \
--cc=dwmw2@infradead.org \
--cc=hch@infradead.org \
--cc=jblunck@suse.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=vaurora@redhat.com \
--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 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).