From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 3/3] xfs: allocate xattr buffer on demand
Date: Thu, 29 Aug 2019 20:45:16 +1000 [thread overview]
Message-ID: <20190829104516.GU1119@dread.disaster.area> (raw)
In-Reply-To: <20190829075559.GC18966@infradead.org>
On Thu, Aug 29, 2019 at 12:55:59AM -0700, Christoph Hellwig wrote:
> On Wed, Aug 28, 2019 at 02:23:50PM +1000, Dave Chinner wrote:
> > + * If ATTR_ALLOC is set in @flags, allocate the buffer for the value after
> > + * existence of the attribute has been determined. On success, return that
> > + * buffer to the caller and leave them to free it. On failure, free any
> > + * allocated buffer and ensure the buffer pointer returned to the caller is
> > + * null.
>
> Given that all three callers pass ATTR_ALLOC, do we even need a flag
Only one caller passes ATTR_ALLOC - the ACL code. The other two
have their own buffers that are supplied....
> and keep the old behavior around, at least at the xfs_attr_get level?
> For the lower level we still have scrub, but that fills out the args
> structure directly.
>
> > +static int
> > +xfs_attr_copy_value(
> > + struct xfs_da_args *args,
> > + unsigned char *value,
> > + int valuelen)
> > +{
> > + /*
> > + * No copy if all we have to do is get the length
> > + */
> > + if (args->flags & ATTR_KERNOVAL) {
> > + args->valuelen = valuelen;
> > + return 0;
> > + }
> > +
> > + /*
> > + * No copy if the length of the existing buffer is too small
> > + */
> > + if (args->valuelen < valuelen) {
> > + args->valuelen = valuelen;
> > + return -ERANGE;
> > + }
> > +
> > + if (args->op_flags & XFS_DA_OP_ALLOCVAL) {
> > + args->value = kmem_alloc_large(valuelen, KM_SLEEP);
> > + if (!args->value)
> > + return -ENOMEM;
> > + }
> > + args->valuelen = valuelen;
>
> Can't we just move the setting of ->valuelen up to common code shared
> between all the branches? That means it would also be set on an
> allocation error, but that should be harmless.
Can't overwrite args->valuelen until we've done the ERANGE check.
Sure, I could put it in a local variable, but that doesn't reduce
the amount of code, or make it obvious that we intentionally return
the attribute size when the supplied buffer it too small...
> > + /* remote block xattr requires IO for copy-in */
> > + if (args->rmtblkno)
> > + return xfs_attr_rmtval_get(args);
> > +
> > + /*
> > + * This is to prevent a GCC warning because the remote xattr case
> > + * doesn't have a value to pass in. In that case, we never reach here,
> > + * but GCC can't work that out and so throws a "passing NULL to
> > + * memcpy" warning.
> > + */
> > + if (!value)
> > + return -EINVAL;
> > + memcpy(args->value, value, valuelen);
> > + return 0;
> > +}
>
> Can you split creating this helper into a separate prep patch? While
> not strictly required it would make reviewing what is consolidation
> vs what is new code for the on-demand buffer allocation a little easier.
ok.
> > + error = xfs_attr_get(ip, ea_name, (unsigned char **)&xfs_acl, &len,
> > + ATTR_ALLOC|ATTR_ROOT);
>
> Please keep space between the symbols and | on each side.
Fixed.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2019-08-29 10:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-28 4:23 [PATCH 0/3 v2] xfs: allocate xattr buffer on demand Dave Chinner
2019-08-28 4:23 ` [PATCH 1/3] xfs: make attr lookup returns consistent Dave Chinner
2019-08-28 22:03 ` Darrick J. Wong
2019-08-29 7:41 ` Christoph Hellwig
2019-08-29 10:32 ` Dave Chinner
2019-08-28 4:23 ` [PATCH 2/3] xfs: move remote attr retrieval into xfs_attr3_leaf_getvalue Dave Chinner
2019-08-28 22:01 ` Darrick J. Wong
2019-08-29 7:46 ` Christoph Hellwig
2019-08-28 4:23 ` [PATCH 3/3] xfs: allocate xattr buffer on demand Dave Chinner
2019-08-28 22:00 ` Darrick J. Wong
2019-08-29 7:55 ` Christoph Hellwig
2019-08-29 10:45 ` Dave Chinner [this message]
2019-08-29 11:02 ` Christoph Hellwig
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=20190829104516.GU1119@dread.disaster.area \
--to=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=linux-xfs@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox