lkml.org 
[lkml]   [2003]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectBug in drivers/block/ll_rw_blk.c ?
A few days ago I posted the report attached below.  After some more
research, I'm starting to think I've hit a bug in ll_rw_blk.c.

If the maintainer of the block dev subsystem happens to be reading
this, please contact me on the list or by mail.

Thanks,
Yoav Weiss

---------- Forwarded message ----------
Date: Tue, 19 Aug 2003 22:34:42 +0300 (IDT)
From: Yoav Weiss <ml-lkml@unpatched.org>
To: linux-kernel@vger.kernel.org
Subject: disk stalls - request disappears until kicked

While researching stalls of a cloop device under recent 2.4.x kernels,
I ran across what seems to be a bug in the request handling initiated by
do_generic_file_read().

The cloop (compressed loop) code I'm debugging is this one:

http://developer.linuxtag.net/knoppix/sources/cloop_1.0-2.tar.gz

I'm testing with kernel 2.4.22-rc2.

The code uses do_generic_file_read() in a similar manner to loop.o.
Under stress-testing, reading processes stall on TASK_UNINTERRUPTIBLE and
remain in that state until another process accesses some non-cached file
on the underlying filesystem. As soon as such access occurs, the stalled
processes resume.

The stalled process waits on a page in mm/filemap.c:1505:

/* Again, try some read-ahead while waiting for the page to finish.. */
generic_file_readahead(reada_ok, filp, inode, page);
------> wait_on_page(page);


I found who wakes it up in calls that don't stall:
unlock_page(), called from
drivers/block/ll_rw_blk.c:end_that_request_first().
bh->b_end_io(bh, uptodate) seems to do it.

Tracking end_that_request_first()'s callers leads all the way back to the
IDE code, and none of it seem to be called on the stalled request until
its kicked by having another process perform some access that causes a
wakeup of the stalled request.

Seems like some request queue doesn't get fully consumed under stress but
so far I've been unable to find what causes it. I'm not even sure if the
request hasn't been passed to the hardware or the hardware handled it and
the BH somehow mishandled it.

Having traced this to the IDE code, I tried the same with a USB disk
instead. It withstood the same stress-testing much longer than the IDE
did, although eventually it stalled in a similar manner. I'm not sure
whether the problem is in ll_rw_blk.c/filemap.c or happens to be shared by
ide and usb-storage/sd.

Curiously, the problem seems to happen when the underlying filesystem is
ext3, but doesn't happen when its vfat as far as I can tell. Could be
related to the fact that ext3 uses generic_file_read and vfat doesn't.

Anyone else experiencing similar stalls ? Suggestions ?

Yoav Weiss



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

\
 
 \ /
  Last update: 2005-03-22 13:47    [W:0.176 / U:0.464 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site