On Friday, September 08, 2006 1:21 PM, Mike Christie wrote > > Edward Goggin wrote: > > + > > + rq->buffer = rq->data = h->buffer; > > + rq->data_len = len; > > + rq->bio = rq->biotail = NULL; > > > > I think I only suggested that you use the block layer map functions in > the previous review. Now I will say, use them and fix the core code to > not allocate memory or use a mempool since it will also fix the path > testers at the same time :) The reason is that the scsi layer > is trying > to make every thing run with scatterlists. In 2.6.18, every place is > converted (they should be at least), so you should not be > adding another > place where we send down a data buffer like this. > Mike, sorry for the long delay. I certainly can (and have tried already before submitting the patch as is) change the code to call blk_rq_map_kern instead of using the code sequence you have identified above. As you cite, I was trying to avoid memory/mempool allocation (for a bio) while servicing the io. As far as fixing the code to not allocate memory or use a mempool, let me know if the description below is what you have in mind? A slightly modified version of __bio_map_kern (and modified versions of its callers like blk_rq_map_kern) which would accept a ptr to bio as a parameter instead of allocating one. Any kernel resident code like a dm-multipath hardware handler could obtain a bio beforehand from a distinct bio_set (bio mempool). In the dm-multipath hardware handler case, a single bio_set could be associated with each target path (struct path). Solving this for the path testing code path is more complicated since the code path is more generic and involves ios initiated from user space. We could move the path testing to within a device mapper ioctl interface which makes it easier to obtain the bio from the path's bio_set and call a slightly modified version of bkl_rq_map_user, bio_map_user, and __bio_map_user_iov. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
