From: Jeff Liu <jeff.liu@oracle.com>
To: Brian Foster <bfoster@redhat.com>
Cc: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>,
linux-kernel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [PATCH] xfs: Fix wrong error codes being returned
Date: Mon, 21 Apr 2014 22:01:34 +0800 [thread overview]
Message-ID: <535524BE.7070704@oracle.com> (raw)
In-Reply-To: <20140421130931.GB24813@bfoster.bfoster>
On 04/21 2014 21:09 PM, Brian Foster wrote:
> On Mon, Apr 21, 2014 at 08:46:39PM +0800, Jeff Liu wrote:
>> Hi Tuomas,
>>
>> On 04/21 2014 18:04 PM, 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>
>>> ---
>>> 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.
>>
>> If I understand right, ops[i].am_error is used to save the internal operation result,
>> i.e, xfs_attrmult_attr_get{set}... but error is used for the ioctl call results.
>> Therefore, assign ERANGE to error is compatible with the VFS set{get}xattr syscalls in
>> case of "if (ops[i].am_error == 0 || ops[i].am_error == MAXNAMELEN)".
>>
>
> But we set 'error' in this case and effectively try to continue the operation
> whereas the traditional vfs path returns...
So the error would always be set to ERANGE if one or more attrname is/are invalid.
>
>> It seems that we don't need to have a break in this case because xfs_attrmulti_by_handle()
>> is used to process multiple attrs. Hence if a given attrname in ops array is invalid,
>> the am_error will indicate that with ENOATTR or EFAULT...but it should proceed to loop
>> through the left array members.
>>
>
> Perhaps so if am_error == 0, but it depends on what attr_name contains
> at that point (stale data?). Otherwise, we try to proceed with a
> truncated name. It looks like the consistent thing to do would be set
> am_error to ERANGE and continue (i.e., skip the op and move on to the
> next).
If we continue to process a truncated name in case of MAXNAMELEN, it would return
EFAULT for SET/REMOVE operations, and ENOATTR for GET operation, which would be
set back to am_error, but error still keep as ERANGE which is consistently.
Thanks,
-Jeff
next prev parent reply other threads:[~2014-04-21 14:01 UTC|newest]
Thread overview: 7+ 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 12:46 ` Jeff Liu
2014-04-21 13:09 ` Brian Foster
2014-04-21 14:01 ` Jeff Liu [this message]
2014-04-21 14:36 ` Brian Foster
2014-04-22 8:17 ` Jeff Liu
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=535524BE.7070704@oracle.com \
--to=jeff.liu@oracle.com \
--cc=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox