----- Original Message -----
> From: "Jonathan Corbet" <cor...@lwn.net>
> To: "Abhi Das" <a...@redhat.com>
> Cc: linux-kernel@vger.kernel.org, linux-fsde...@vger.kernel.org,
> cluster-de...@redhat.com
> Sent: Tuesday, July 29, 2014 1:58:08 PM
> Subject: Re: [RFC PATCH 5/5] gfs2: Add xreaddir file operation and supporting
> functions
>
> On Fri, 25 Jul 2014 12:38:08 -0500
> Abhi Das <a...@redhat.com> wrote:
>
> > This patch adds support in GFS2 for the xgetdents syscall by
> > implementing the xreaddir file operation.
>
> So I was trying to make sense of this, and ran into one little thing that
> jumped out at me:
>
> > +static int gfs2_xrdir_to_user_vars(struct gfs2_xrdir_ctx *xc,
> > + struct gfs2_xdirent *x,
> > + struct gfs2_xdirent *x_vb_p,
> > + struct linux_xdirent __user *lxd,
> > + size_t count, size_t *bytes)
>
> Now, I'll readily admit that I could be overly confused by this function.
> When the variables are named "x", "xx", "xc", "x_vb_p", "xblob", and "lxd",
> it all starts to run together. But still...
>
As I went along writing this patch, I ended up needing more structs and names
and this is
the ugly result :(. I guess some of these structs/names can be reviewed and
changed as
needed. This is just a proof of concept patch to illustrate how such a syscall
can be
implemented.
> > + if ((xc->xc_xattr_mask & XSTAT_XATTR_ALL) &&
> > + lxd->xd_blob.xb_xattr_count) {
>
> How can that be right? lxd is __user, it doesn't seem right to be
> dereferencing it directly...?
Wouldn't the call to access_ok() at the start of the syscall take care of this?
All the
__user pointers point to areas within the user supplied buffer buf and overflow
past the
end of the buffer for the last lxd is checked for.
The 2/5 patch in this series adds the following in fs/readdir.c:
+SYSCALL_DEFINE5(xgetdents, unsigned int, fd, unsigned, flags, unsigned int,
mask,
+ void __user *, buf, unsigned int, count)
...
...
...
+ if (!access_ok(VERIFY_WRITE, buf, count))
+ return -EFAULT;
>
> Thanks,
>
> jon
>
Cheers!
--Abhi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
