Re: BUG in VFS or block layer

From: Nick Piggin
Date: Wed Aug 06 2008 - 22:13:20 EST


On Thursday 07 August 2008 07:28, Andrew Morton wrote:
[...]

I'll have a go at reproducing it if I can.


> Aside: why does this code in do_generic_file_read() return -EIO when it
> got a signal?
>
>
> page_not_up_to_date:
> /* Get exclusive access to the page ... */
> if (lock_page_killable(page))
> goto readpage_eio;

I wondered about that too, but the error never gets back to userspace, so
we just want something that is going to return quickly.


> 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?

That seems likely.


> Aside2: why does this code:
>
> 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;
> }
>
> if (!PageUptodate(page)) {
> if (lock_page_killable(page))
> goto readpage_eio;
>
> return EIO if lock_page_killable() saw a signal?

Same as above.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/