lkml.org 
[lkml]   [2008]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: BUG in VFS or block layer
On Wed, 6 Aug 2008 18:40:54 -0400 (EDT)
Alan Stern <stern@rowland.harvard.edu> wrote:

> On Wed, 6 Aug 2008, Andrew Morton wrote:
>
> > What the VFS will do is
> >
> > - lock the page
> >
> > - put the page into a BIO and send it down to the block layer
> >
> > - later, wait for IO completion. It does this by running
> > lock_page[_killable](), which will waiting for the page to come unlocked.
> >
> > The page comes unlocked via the device driver, usually within the
> > IO completion interrupt.
> >
> >
> > A common cause of userspace lockups during IO errors is that the driver
> > layer screwed up and didn't run the completion callback.
> >
> > Now, according to the above trace, the above code sequence _did_ work
> > OK. Or at least, it ran to completion. It was later, when we tried to
> > truncate a file that we stumbled across a permanently-locked page.
> >
> > So it would appear that the VFS read() code successfully completed, but
> > left locked pages behind it, which caused the truncate to hang.
>
> ...
>
> > One possible problem is here:
> >
> > readpage:
> > /* Start the actual read. The read will unlock the page. */
> > error = mapping->a_ops->readpage(filp, page);
> >
> > if (unlikely(error)) {
> > if (error == AOP_TRUNCATED_PAGE) {
> > page_cache_release(page);
> > goto find_page;
> > }
> > goto readpage_error;
> > }
> >
> > the VFS layer assumes that if ->readpage() returned a synchronous error
> > then the page was already unlocked within ->readpage(). Usually this
> > means that the driver layer had to run the BIO completion callback to
> > do that unlocking. It is possible that the USB code forgot to do this.
> > This would explain what you're seeing.
> >
> > So... would you be able to verify that the USB, layer is correctly
> > calling bio->bi_end_io() for the offending requests?
>
> The USB layer doesn't handle that; the SCSI layer takes care of it.
> Possibly the I/O error confuses the code in and around
> scsi_end_request(). I'll have to do some testing to find out.
>

Well... looking at your patch to
drivers/usb/gadget/file_storage.c:do_read(), it appears that
do_scsi_command() just drops do_read()'s error code on the floor rather
than returning it to the scsi layer?



\
 
 \ /
  Last update: 2008-08-07 00:59    [W:0.043 / U:0.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site