Re: [PATCH][noop-iosched] don't reuse a freed request

[Arnaldo Carvalho de Melo]

Em Mon, Oct 31, 2005 at 12:55:26AM -0200, Arnaldo Carvalho de Melo escreveu:
> Em Mon, Oct 31, 2005 at 12:30:24AM -0200, Arnaldo Carvalho de Melo escreveu:
> > Hi,
> > 
> > 	I'm getting the oops below when trying to use qemu with a kernel
> > built with just the noop iosched, I'm never had looked at this code before,
> > so I did a quick hack that seems enough for my case.
> > 
> > 	Ah, this is with a fairly recent git tree (today), haven't checked
> > if it is present in 2.6.14.
> 
> Further info: building with all the io schedulers and using 'elevator=cfq'
> in the kernel cmd line produces another oops, with or without my patch:
> 
> hda:<1>Unable to handle kernel paging request at virtual address c554ef60
> printing eip:
> 01b14f7
> pde = 00015067
> pte = 0554e000
> ops: 0000 [#1]
> EBUG_PAGEALLOC
> odules linked in:
> PU:    0
> IP:    0060:[<c01b14f7>]    Not tainted VLI
> FLAGS: 00000046   (2.6.14acme)
> IP is at __elv_add_request+0xe7/0x13f

Ok, some more info, hope it'll be useful: I narrowed it down to this part
of __elv_add_request:

	case ELEVATOR_INSERT_SORT:
                BUG_ON(!blk_fs_request(rq));
                rq->flags |= REQ_SORTED;
                q->elevator->ops->elevator_add_req_fn(q, rq);
                if (q->last_merge == NULL && rq_mergeable(rq))
                        q->last_merge = rq;
                break;

It seems it is not safe to touch the request (rq) after calling
elevator_add_req_fn, as the panic happens when rq_mergeable tries
to read rq->flags, or cfq_insert_request is doing something bad, well,
enough for my block layer wanderings :-)

Best Regards,

- Arnaldo

P.S. the last patches to touch this code are post 2.6.14
-
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/