On Mon, Apr 21, 2014 at 10:01:34PM +0800, Jeff Liu wrote:
>
> 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@xxxxxx>
> >>> ---
> >>> 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.
>
Right...
> >
> >> 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.
>
Ah, we should hit an error in the xfs_attr_name_to_xname() call
deeper in the callchain, so the truncated name case should not be an
issue. The am_error == 0 case still looks weird to me.
So we return an error and set am_error if there's an issue with the attr
name. If there's another error in the op path, we set am_error only and
continue on. Not being familiar with the interface, I'm curious if there
is any particular reason for that difference in behavior. It seems like
the caller should process all of the return codes anyways.
Brian
>
> Thanks,
> -Jeff
>
> _______________________________________________
> xfs mailing list
> xfs@xxxxxxxxxxx
> http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
