From: Brian Foster <bfoster@redhat.com>
To: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [PATCH] xfs: Fix wrong error codes being returned
Date: Mon, 21 Apr 2014 09:01:14 -0400 [thread overview]
Message-ID: <20140421130113.GA24813@bfoster.bfoster> (raw)
In-Reply-To: <1398074687-26548-1-git-send-email-tuomas.tynkkynen@iki.fi>
On Mon, Apr 21, 2014 at 01:04:47PM +0300, Tuomas Tynkkynen wrote:
> xfs_{compat_,}attrmulti_by_handle could return an errno with incorrect
> sign in some cases. While at it, make sure ENOMEM is returned instead of
> E2BIG if kmalloc fails.
>
> Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
> ---
The fix looks good to me. There has been talk recently of starting to
fix up our internal positive-to-negative error conversions to be more
consistent with the rest of the kernel. Given that, I wonder if it's
better here to go the other way. E.g., remove the negation in the
out_dput path and convert the positive error codes (and thus we don't
need to add more negative-to-positive-to-negative conversions here).
Thoughts?
Brian
> Compile tested only. For the ERANGE case, I also wonder if it should
> be assigning to ops[i].am_error instead of error, and/or have a break.
>
> fs/xfs/xfs_ioctl.c | 5 +++--
> fs/xfs/xfs_ioctl32.c | 5 +++--
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
> index 0b18776..2d8f4fd 100644
> --- a/fs/xfs/xfs_ioctl.c
> +++ b/fs/xfs/xfs_ioctl.c
> @@ -543,10 +543,11 @@ xfs_attrmulti_by_handle(
>
> ops = memdup_user(am_hreq.ops, size);
> if (IS_ERR(ops)) {
> - error = PTR_ERR(ops);
> + error = -PTR_ERR(ops);
> goto out_dput;
> }
>
> + error = ENOMEM;
> attr_name = kmalloc(MAXNAMELEN, GFP_KERNEL);
> if (!attr_name)
> goto out_kfree_ops;
> @@ -556,7 +557,7 @@ xfs_attrmulti_by_handle(
> ops[i].am_error = strncpy_from_user((char *)attr_name,
> ops[i].am_attrname, MAXNAMELEN);
> if (ops[i].am_error == 0 || ops[i].am_error == MAXNAMELEN)
> - error = -ERANGE;
> + error = ERANGE;
> if (ops[i].am_error < 0)
> break;
>
> diff --git a/fs/xfs/xfs_ioctl32.c b/fs/xfs/xfs_ioctl32.c
> index a7992f8..944d5ba 100644
> --- a/fs/xfs/xfs_ioctl32.c
> +++ b/fs/xfs/xfs_ioctl32.c
> @@ -424,10 +424,11 @@ xfs_compat_attrmulti_by_handle(
>
> ops = memdup_user(compat_ptr(am_hreq.ops), size);
> if (IS_ERR(ops)) {
> - error = PTR_ERR(ops);
> + error = -PTR_ERR(ops);
> goto out_dput;
> }
>
> + error = ENOMEM;
> attr_name = kmalloc(MAXNAMELEN, GFP_KERNEL);
> if (!attr_name)
> goto out_kfree_ops;
> @@ -438,7 +439,7 @@ xfs_compat_attrmulti_by_handle(
> compat_ptr(ops[i].am_attrname),
> MAXNAMELEN);
> if (ops[i].am_error == 0 || ops[i].am_error == MAXNAMELEN)
> - error = -ERANGE;
> + error = ERANGE;
> if (ops[i].am_error < 0)
> break;
>
> --
> 1.7.9.5
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
WARNING: multiple messages have this Message-ID (diff)
From: Brian Foster <bfoster@redhat.com>
To: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Cc: Dave Chinner <david@fromorbit.com>,
linux-kernel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [PATCH] xfs: Fix wrong error codes being returned
Date: Mon, 21 Apr 2014 09:01:14 -0400 [thread overview]
Message-ID: <20140421130113.GA24813@bfoster.bfoster> (raw)
In-Reply-To: <1398074687-26548-1-git-send-email-tuomas.tynkkynen@iki.fi>
On Mon, Apr 21, 2014 at 01:04:47PM +0300, Tuomas Tynkkynen wrote:
> xfs_{compat_,}attrmulti_by_handle could return an errno with incorrect
> sign in some cases. While at it, make sure ENOMEM is returned instead of
> E2BIG if kmalloc fails.
>
> Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
> ---
The fix looks good to me. There has been talk recently of starting to
fix up our internal positive-to-negative error conversions to be more
consistent with the rest of the kernel. Given that, I wonder if it's
better here to go the other way. E.g., remove the negation in the
out_dput path and convert the positive error codes (and thus we don't
need to add more negative-to-positive-to-negative conversions here).
Thoughts?
Brian
> Compile tested only. For the ERANGE case, I also wonder if it should
> be assigning to ops[i].am_error instead of error, and/or have a break.
>
> fs/xfs/xfs_ioctl.c | 5 +++--
> fs/xfs/xfs_ioctl32.c | 5 +++--
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
> index 0b18776..2d8f4fd 100644
> --- a/fs/xfs/xfs_ioctl.c
> +++ b/fs/xfs/xfs_ioctl.c
> @@ -543,10 +543,11 @@ xfs_attrmulti_by_handle(
>
> ops = memdup_user(am_hreq.ops, size);
> if (IS_ERR(ops)) {
> - error = PTR_ERR(ops);
> + error = -PTR_ERR(ops);
> goto out_dput;
> }
>
> + error = ENOMEM;
> attr_name = kmalloc(MAXNAMELEN, GFP_KERNEL);
> if (!attr_name)
> goto out_kfree_ops;
> @@ -556,7 +557,7 @@ xfs_attrmulti_by_handle(
> ops[i].am_error = strncpy_from_user((char *)attr_name,
> ops[i].am_attrname, MAXNAMELEN);
> if (ops[i].am_error == 0 || ops[i].am_error == MAXNAMELEN)
> - error = -ERANGE;
> + error = ERANGE;
> if (ops[i].am_error < 0)
> break;
>
> diff --git a/fs/xfs/xfs_ioctl32.c b/fs/xfs/xfs_ioctl32.c
> index a7992f8..944d5ba 100644
> --- a/fs/xfs/xfs_ioctl32.c
> +++ b/fs/xfs/xfs_ioctl32.c
> @@ -424,10 +424,11 @@ xfs_compat_attrmulti_by_handle(
>
> ops = memdup_user(compat_ptr(am_hreq.ops), size);
> if (IS_ERR(ops)) {
> - error = PTR_ERR(ops);
> + error = -PTR_ERR(ops);
> goto out_dput;
> }
>
> + error = ENOMEM;
> attr_name = kmalloc(MAXNAMELEN, GFP_KERNEL);
> if (!attr_name)
> goto out_kfree_ops;
> @@ -438,7 +439,7 @@ xfs_compat_attrmulti_by_handle(
> compat_ptr(ops[i].am_attrname),
> MAXNAMELEN);
> if (ops[i].am_error == 0 || ops[i].am_error == MAXNAMELEN)
> - error = -ERANGE;
> + error = ERANGE;
> if (ops[i].am_error < 0)
> break;
>
> --
> 1.7.9.5
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-04-21 13:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-21 10:04 [PATCH] xfs: Fix wrong error codes being returned Tuomas Tynkkynen
2014-04-21 10:04 ` Tuomas Tynkkynen
2014-04-21 12:46 ` Jeff Liu
2014-04-21 12:46 ` Jeff Liu
2014-04-21 13:09 ` Brian Foster
2014-04-21 13:09 ` Brian Foster
2014-04-21 14:01 ` Jeff Liu
2014-04-21 14:01 ` Jeff Liu
2014-04-21 14:36 ` Brian Foster
2014-04-21 14:36 ` Brian Foster
2014-04-22 8:17 ` Jeff Liu
2014-04-22 8:17 ` Jeff Liu
2014-04-21 13:01 ` Brian Foster [this message]
2014-04-21 13:01 ` Brian Foster
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=20140421130113.GA24813@bfoster.bfoster \
--to=bfoster@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tuomas.tynkkynen@iki.fi \
--cc=xfs@oss.sgi.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.