[PATCH] loop sendfile retval

[PATCH] loop sendfile retval

[Hugh Dickins]

Buffer I/O error on device loop: its use of sendfile is (trivially)
broken - retval is usually count done, only an error when negative.
Nearby spinlocking clearly bogus, delete instead of remarking on it.

Hugh

--- 2.5.47/drivers/block/loop.c	Mon Nov 11 12:34:14 2002
+++ linux/drivers/block/loop.c	Mon Nov 11 15:44:33 2002
@@ -304,21 +304,16 @@
 {
 	struct lo_read_data cookie;
 	struct file *file;
-	int error;
+	int retval;
 
 	cookie.lo = lo;
 	cookie.data = kmap(bvec->bv_page) + bvec->bv_offset;
 	cookie.bsize = bsize;
-
-	/* umm, what does this lock actually try to protect? */
-	spin_lock_irq(&lo->lo_lock);
 	file = lo->lo_backing_file;
-	spin_unlock_irq(&lo->lo_lock);
-
-	error = file->f_op->sendfile(file, &pos, bvec->bv_len,
+	retval = file->f_op->sendfile(file, &pos, bvec->bv_len,
 			lo_read_actor, &cookie);
 	kunmap(bvec->bv_page);
-	return error;
+	return (retval < 0)? retval: 0;
 }
 
 static int

Re: [PATCH] loop sendfile retval

[Linus Torvalds]

On Mon, 11 Nov 2002, Hugh Dickins wrote:
>
> Buffer I/O error on device loop: its use of sendfile is (trivially)
> broken - retval is usually count done, only an error when negative.

Hmm.. Sendfile can return other values than "count" (ie a partial read).  
This return value change makes "do_lo_receive()" lose that information. As 
such, the new do_lo_receive() is weaker than the old one.

If fixing the loop code to handle partial IO is too nasty, then I would
suggest doing maybe something like

	if (ret > 0 && ret != bvec->bv_len)
		ret = -EIO;

which at least makes a partial IO an error instead of making it a success 
case (the code as-is seems to think that any non-negative return value 
means that the IO was fully successful).

> Nearby spinlocking clearly bogus, delete instead of remarking on it.

I'll apply the patch, it looks better than what is there now, but it might 
be worth fixing this _right_.

		Linus

Re: [PATCH] loop sendfile retval

[Hugh Dickins]

On Mon, 11 Nov 2002, Linus Torvalds wrote:
> On Mon, 11 Nov 2002, Hugh Dickins wrote:
> >
> > Buffer I/O error on device loop: its use of sendfile is (trivially)
> > broken - retval is usually count done, only an error when negative.
> 
> Hmm.. Sendfile can return other values than "count" (ie a partial read).  
> This return value change makes "do_lo_receive()" lose that information. As 
> such, the new do_lo_receive() is weaker than the old one.

True, with that patch it's passing back less info than 2.5.47 tried to do;
but no less than 2.5.46 and earlier, which always returned desc.error and
ignored the desc.written, desc.count coming back from do_generic_file_read.
So it's not a regression, but of course you're right that it's weak.

> If fixing the loop code to handle partial IO is too nasty, then I would
> suggest doing maybe something like
> 
> 	if (ret > 0 && ret != bvec->bv_len)
> 		ret = -EIO;
> 
> which at least makes a partial IO an error instead of making it a success 
> case (the code as-is seems to think that any non-negative return value 
> means that the IO was fully successful).
> 
> > Nearby spinlocking clearly bogus, delete instead of remarking on it.
> 
> I'll apply the patch, it looks better than what is there now, but it might 
> be worth fixing this _right_.

Thanks, that gets it going again.  I'll step aside and leave the correct
partial handling to those who know loop much better than I - Adam?

Hugh