Hi Vincent -
Yes, this was fixed about 5 weeks ago in CVS.
The tricky part is that XFS uses positive error values internally,
while Linux expects negative errors. (Linux often uses a single
variable for returns, returning negative errors and positive
results, i.e. either -EPERM or (+)bytes_written). XFS doesn't usually
overload return values like this. In any case, when we transition from
the internals of XFS out ot linux (i.e. the linvfs_* functions) we need to
keep careful track of error signs.
So, VOP_WRITE (which is essentially xfs_write) returns positive errors,
but other constant assignments in linvfs_write set err to be negative.
The out: target had always been flipping the sign of the error, but
this was only correct for errors from VOP_WRITE. The change was made
to explicitly sign-flip the VOP_WRITE error return, and otherwise
return errors as they are.
-Eric
On Sun, 21 Apr 2002, Vincent Bernat wrote:
> Well, I have tried with a 2.4.18 and the problem is the same.
> I have searched where the SIG_XFSZ signal is triggered and it is in
> xfs_file.c. I think the error is here. The "err" variable is set to a
> negative value and if it is non null, the opposite is returned. I
> think that we must return the positive value :
>
> return(err ? err : count);
>
> instead of
>
> return(err ? -err : count);
>
> But I suppose that the sign flipping was here for something. The only
> function that uses err (besides simple constant assignations) is the
> macro VOP_WRITE which I suppose finally calls xfs_write. xfs_write is
> said to return positive error value. So I suppose, that the above
> change is correct and the sign flipping must occur only after the call
> to xfs_write.
>
> Am I missing something ?
--
Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs
sandeen@xxxxxxx SGI, Inc.
|