On Tue, Feb 18, 2020 at 04:39:24PM +0100, Christoph Hellwig wrote:
> On Tue, Feb 18, 2020 at 10:53:16AM +1100, Dave Chinner wrote:
> > > diff --git a/fs/xfs/libxfs/xfs_fs.h b/fs/xfs/libxfs/xfs_fs.h
> > > index ae77bcd8c05b..21920f613d42 100644
> > > --- a/fs/xfs/libxfs/xfs_fs.h
> > > +++ b/fs/xfs/libxfs/xfs_fs.h
> > > @@ -597,7 +597,7 @@ typedef struct xfs_fsop_attrlist_handlereq {
> > > struct xfs_attrlist_cursor pos; /* opaque cookie, list offset */
> > > __u32 flags; /* which namespace to use */
> > > __u32 buflen; /* length of buffer supplied */
> > > - void __user *buffer; /* returned names */
> > > + struct xfs_attrlist __user *buffer;/* returned names */
> > > } xfs_fsop_attrlist_handlereq_t;
> >
> > This changes the userspace API, right? So, in theory, it could break
> > compilation of userspace applications that treat it as an attrlist_t
> > and don't specifically cast the assignment because it's currently
> > a void pointer?
>
> IFF userspace was using this header it would change the API. But
> userspace uses the libattr definition exclusively.
Assuming most userspace will use libhandle (and not call the ioctl
directly) then this "shouldn't" be a problem because libhandle treats
the attrlist buffer as a void pointer.
(I dunno, how difficult /is/ it to say "program to the library, not the
kernel ABI" here?)
--D
