Messages in this thread | | | From | "Adam J. Richter" <> | Date | Wed, 5 Jun 2002 18:02:43 -0700 | Subject | Re: Patch: linux-2.5.20/fs/bio.c - ll_rw_kio made incorrect assumptions about queue handler's capabilities |
| |
Andrew Morton <akpm@zip.com.au> writes: >What particular problem are you trying to solve here?
In 2.5.20, ll_rw_kio could submit bio's that are too big for the underlying queue to handle (they might have more sectors than q->max_sectors, more iovec's than q->max_phys_segments or q->max_hw_segments).
As a hypothetical example, suppose that ll_rw_kio is called to copy 148kB of data (37 4kB pages on x86) to a Compaq Smart2 raid controller. Assume also that the pages are not contiguous in physical memory and there is no iommu to make them look contiguous to a DMA device, so there will be no merging.
In this example, ll_rw_kio in linux-2.5.20 would handle this call by building a single bio with 37 iovec's and pass it in a single call to submit_bio. Nothing in the request merging code in drivers/block/ll_rw_blk.c will break up this bio. blk_recount_segments will fill in bio->bi_phys_segments and bio->bi_hw_segments as 37 (because there is no merging to make it any smaller). blk_recalc_rq_segments will then set rq->nr_phys_segments to 37 (the request will contain only this one bio, becasue bio->bi_phys_segments already excceds q->max_phys_segments).
Eventually, do_cciss_request (in drivers/block/cciss.c) will extract the request containing the bio with bio->bi_phys_segments == 37. request and generate a kernel panic because the number of segements exceeds 32. In the case of linux-2.5.20/drivers/block/cciss.c, this happens around line 1799:
creq = elv_next_request(q); if (creq->nr_phys_segments > MAXSGENTRIES) BUG();
Adam J. Richter __ ______________ 575 Oroville Road adam@yggdrasil.com \ / Milpitas, California 95035 +1 408 309-6081 | g g d r a s i l United States of America "Free Software For The Rest Of Us." - 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/
| |