Re: 2.4.20: Proccess stuck in __lock_page ...

Andrew Morton (akpm@digeo.com)
Wed, 28 May 2003 00:51:56 -0700


Jens Axboe <axboe@suse.de> wrote:
>
> > that one, the answer is YES.
>
> That's the one, yes. Andrew, looks like your patch brought out some
> really bad behaviour.

Yes, but why?

It'd be interesting if any of these changes make a difference.

drivers/block/ll_rw_blk.c | 7
fs/buffer.c | 3030 ++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 3033 insertions(+), 4 deletions(-)

diff -puN drivers/block/ll_rw_blk.c~a drivers/block/ll_rw_blk.c
--- 24/drivers/block/ll_rw_blk.c~a 2003-05-28 00:48:09.000000000 -0700
+++ 24-akpm/drivers/block/ll_rw_blk.c 2003-05-28 00:50:02.000000000 -0700
@@ -590,10 +590,10 @@ static struct request *__get_request_wai
register struct request *rq;
DECLARE_WAITQUEUE(wait, current);

- generic_unplug_device(q);
- add_wait_queue_exclusive(&q->wait_for_requests[rw], &wait);
+ add_wait_queue(&q->wait_for_requests[rw], &wait);
do {
set_current_state(TASK_UNINTERRUPTIBLE);
+ generic_unplug_device(q);
if (q->rq[rw].count == 0)
schedule();
spin_lock_irq(&io_request_lock);
@@ -829,8 +829,7 @@ void blkdev_release_request(struct reque
*/
if (q) {
list_add(&req->queue, &q->rq[rw].free);
- if (++q->rq[rw].count >= q->batch_requests &&
- waitqueue_active(&q->wait_for_requests[rw]))
+ if (++q->rq[rw].count >= q->batch_requests)
wake_up(&q->wait_for_requests[rw]);
}
}

_

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