[Yaffs] write operation returns incorrect value in case device is out of space

[Mikhail Ryleev]

On 12/22/05, Todd Poynor <tpoynor at mvista.com> wrote:
>
> Mikhail Ryleev wrote:
>
> > It also fixes a problem with partially written data that actually should
> > return the amount of data written.
>
> May be OK, most callers will simply treat as an error, but various other
> commit_write implementations don't do this.  What code expects a partial
> count return?


For example it is called by generic_file_write routine which is an
implementation of "write" call.
Since it is that generic, we have to be extremely careful what we return
here.
As for partial count return,  if we change the state of the file, advance
file pointer or change the size of the file,
we have to let the caller know that that happened. An alternative would be
to completely discard changes,
probably it is much better but far more complex.


> 2. device is out of space while creating new object. In this case
> > current code returns ENOMEM error code which is also misleading.
> > Unfortunatly, I do not see a simple fix here,  the structure of code is
> > such that it is hard to diffirenciate out-of-memory vs. out-of-space
> > situation here but I think ENOSPC would be better here because it is
> > more likely to happen.
> >
> >...
> > @@ -785,7 +784,7 @@
> >   }
> >   yaffs_GrossUnlock(dev);
> >
> > - return nWritten != n ? -ENOSPC : nWritten;
> > +   return ( nWritten == n || nWritten > 0 ) ? nWritten : -ENOSPC;
>
> Can't match the code change to the description above, how was ENOMEM
> returned before?


ENOMEM is returned by yaffs_mknod call in case it failed to create new
object for whatever reason and not in that patch.
I do not have simple solution for that, other then replace it with ENOSPC
which is arguably not much better.


Is a check for nWritten < 0 (-ENOMEM) appropriate?  Or else ( nWritten
> == n || nWritten > 0 ) can simply be nWritten > 0 .
>
> --
> Todd
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.aleph1.co.uk/pipermail/yaffs/attachments/20051222/906db2f0/attachment.html