All of lore.kernel.org
 help / color / mirror / Atom feed
From: Clay Harris <bugs@claycon.org>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Stefan Roesch <shr@fb.com>,
	io-uring@vger.kernel.org,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH v1 0/5] io_uring: add xattr support
Date: Tue, 30 Nov 2021 00:53:45 -0600	[thread overview]
Message-ID: <20211130065345.actf2vrfpvtk6fcz@ps29521.dreamhostps.com> (raw)
In-Reply-To: <20211130063703.hszzs3tg5qb37fyj@ps29521.dreamhostps.com>

On Tue, Nov 30 2021 at 00:37:03 -0600, Clay Harris quoth thus:

> On Mon, Nov 29 2021 at 20:16:02 -0700, Andreas Dilger quoth thus:
> 
> > 
> > > On Nov 29, 2021, at 6:08 PM, Clay Harris <bugs@claycon.org> wrote:
> > > 
> > > On Mon, Nov 29 2021 at 14:12:52 -0800, Stefan Roesch quoth thus:
> > > 
> > >> This adds the xattr support to io_uring. The intent is to have a more
> > >> complete support for file operations in io_uring.
> > >> 
> > >> This change adds support for the following functions to io_uring:
> > >> - fgetxattr
> > >> - fsetxattr
> > >> - getxattr
> > >> - setxattr
> > > 
> > > You may wish to consider the following.
> > > 
> > > Patching for these functions makes for an excellent opportunity
> > > to provide a better interface.  Rather than implement fXetattr
> > > at all, you could enable io_uring to use functions like:
> > > 
> > > int Xetxattr(int dfd, const char *path, const char *name,
> > > 	[const] void *value, size_t size, int flags);
> > 
> > This would naturally be named "...xattrat()"?
> 
> Indeed!
> 
> > > Not only does this simplify the io_uring interface down to two
> > > functions, but modernizes and fixes a deficit in usability.
> > > In terms of io_uring, this is just changing internal interfaces.
> > 
> > Even better would be the ability to get/set an array of xattrs in
> > one call, to avoid repeated path lookups in the common case of
> > handling multiple xattrs on a single file.
> 
> True.
> 
> > > Although unnecessary for io_uring, it would be nice to at least
> > > consider what parts of this code could be leveraged for future
> > > Xetxattr2 syscalls.
> s/Xetxattr2/Xetxattrat/

I forgot to mention a final thought about the interface.
Unless there is a really good reason (security auditing??), there
is no reason to have a removexattr() function.  That seems much
better handled by passing NULL for value and specifying a remove
flag in flags to setxattrat().

> > > 
> > >> Patch 1: fs: make user_path_at_empty() take a struct filename
> > >>  The user_path_at_empty filename parameter has been changed
> > >>  from a const char user pointer to a filename struct. io_uring
> > >>  operates on filenames.
> > >>  In addition also the functions that call user_path_at_empty
> > >>  in namei.c and stat.c have been modified for this change.
> > >> 
> > >> Patch 2: fs: split off setxattr_setup function from setxattr
> > >>  Split off the setup part of the setxattr function
> > >> 
> > >> Patch 3: fs: split off the vfs_getxattr from getxattr
> > >>  Split of the vfs_getxattr part from getxattr. This will
> > >>  allow to invoke it from io_uring.
> > >> 
> > >> Patch 4: io_uring: add fsetxattr and setxattr support
> > >>  This adds new functions to support the fsetxattr and setxattr
> > >>  functions.
> > >> 
> > >> Patch 5: io_uring: add fgetxattr and getxattr support
> > >>  This adds new functions to support the fgetxattr and getxattr
> > >>  functions.
> > >> 
> > >> 
> > >> There are two additional patches:
> > >>  liburing: Add support for xattr api's.
> > >>            This also includes the tests for the new code.
> > >>  xfstests: Add support for io_uring xattr support.
> > >> 
> > >> 
> > >> Stefan Roesch (5):
> > >>  fs: make user_path_at_empty() take a struct filename
> > >>  fs: split off setxattr_setup function from setxattr
> > >>  fs: split off the vfs_getxattr from getxattr
> > >>  io_uring: add fsetxattr and setxattr support
> > >>  io_uring: add fgetxattr and getxattr support
> > >> 
> > >> fs/internal.h                 |  23 +++
> > >> fs/io_uring.c                 | 325 ++++++++++++++++++++++++++++++++++
> > >> fs/namei.c                    |   5 +-
> > >> fs/stat.c                     |   7 +-
> > >> fs/xattr.c                    | 114 +++++++-----
> > >> include/linux/namei.h         |   4 +-
> > >> include/uapi/linux/io_uring.h |   8 +-
> > >> 7 files changed, 439 insertions(+), 47 deletions(-)
> > >> 
> > >> 
> > >> Signed-off-by: Stefan Roesch <shr@fb.com>
> > >> base-commit: c2626d30f312afc341158e07bf088f5a23b4eeeb
> > >> --
> > >> 2.30.2
> > 
> > 
> > Cheers, Andreas
> > 
> > 
> > 
> > 
> > 
> 

  reply	other threads:[~2021-11-30  6:53 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-29 22:12 [PATCH v1 0/5] io_uring: add xattr support Stefan Roesch
2021-11-29 22:12 ` [PATCH v1 1/5] fs: make user_path_at_empty() take a struct filename Stefan Roesch
2021-11-30  2:09   ` kernel test robot
2021-11-30  2:09     ` kernel test robot
2021-11-29 22:12 ` [PATCH v1 2/5] fs: split off setxattr_setup function from setxattr Stefan Roesch
2021-11-29 22:12 ` [PATCH v1 3/5] fs: split off the vfs_getxattr from getxattr Stefan Roesch
2021-11-30 13:40   ` [fs] 23a831cdec: WARNING:at_include/linux/thread_info.h:#do_getxattr kernel test robot
2021-11-30 13:40     ` kernel test robot
2021-11-29 22:12 ` [PATCH v1 4/5] io_uring: add fsetxattr and setxattr support Stefan Roesch
2021-11-29 22:12 ` [PATCH v1 5/5] io_uring: add fgetxattr and getxattr support Stefan Roesch
2021-11-30  1:08 ` [PATCH v1 0/5] io_uring: add xattr support Clay Harris
2021-11-30  3:16   ` Andreas Dilger
2021-11-30  6:37     ` Clay Harris
2021-11-30  6:53       ` Clay Harris [this message]
2021-11-30 11:40         ` Clay Harris
2021-11-30  7:19     ` Dave Chinner
2021-12-01  6:16     ` Stefan Roesch
2021-12-01  6:07   ` Stefan Roesch
2021-12-01  7:46     ` Clay Harris
2021-12-01 13:14       ` Christian Brauner
2021-12-01 12:19     ` Stefan Metzmacher
2021-12-01 19:52       ` Clay Harris
2021-12-01 20:05         ` Andreas Dilger
2021-12-03 17:58       ` Stefan Roesch

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=20211130065345.actf2vrfpvtk6fcz@ps29521.dreamhostps.com \
    --to=bugs@claycon.org \
    --cc=adilger@dilger.ca \
    --cc=io-uring@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=shr@fb.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.