All of lore.kernel.org
 help / color / mirror / Atom feed
From: Olga Kornievskaia <aglo@umich.edu>
To: Andreas Gruenbacher <agruen@kernel.org>,
	"J. Bruce Fields" <bfields@redhat.com>
Cc: linux-nfs <linux-nfs@vger.kernel.org>
Subject: extended attributes limitation of xattr_size_max
Date: Thu, 2 Jan 2020 17:28:44 -0500	[thread overview]
Message-ID: <CAN-5tyEg2b1CnbJrc-Hf2406cPWCAOjYcpPq0FremYjFXsytDQ@mail.gmail.com> (raw)

Hi Andreas and Bruce,

I thought of you folks as somebody who might have a strong opinion on
the topic. Right now an NFS client is limited to setting and getting
ACLs that can't be larger than 64K (XATTR_SIZE_MAX) (where some NFS
server don't have such limit on the ACL size). There are limits in
fs/xattr.c during getting and setting xattrs. I believe that's because
linux local xattr system is limited to that particular constraint.
However, an NFS acl that uses the xattr interface can be larger than
that. Is it at all possible to suggest to the larger FS community to
remove those limits or would that be a non-starter?

diff --git a/fs/xattr.c b/fs/xattr.c
index 90dd78f..52a3f91 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -428,8 +428,6 @@ int __vfs_setxattr_noperm(struct dentry *dentry,
const char *name,
  return error;

  if (size) {
- if (size > XATTR_SIZE_MAX)
- return -E2BIG;
  kvalue = kvmalloc(size, GFP_KERNEL);
  if (!kvalue)
  return -ENOMEM;
@@ -528,8 +526,6 @@ static int path_setxattr(const char __user *pathname,
  return error;

  if (size) {
- if (size > XATTR_SIZE_MAX)
- size = XATTR_SIZE_MAX;
  kvalue = kvzalloc(size, GFP_KERNEL);
  if (!kvalue)
  return -ENOMEM;
--

             reply	other threads:[~2020-01-02 22:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-02 22:28 Olga Kornievskaia [this message]
2020-01-02 23:31 ` extended attributes limitation of xattr_size_max Frank van der Linden
2020-01-03 16:13   ` Olga Kornievskaia
2020-01-03 17:18     ` Olga Kornievskaia

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=CAN-5tyEg2b1CnbJrc-Hf2406cPWCAOjYcpPq0FremYjFXsytDQ@mail.gmail.com \
    --to=aglo@umich.edu \
    --cc=agruen@kernel.org \
    --cc=bfields@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    /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.