Messages in this thread | | | Date | Wed, 01 Apr 2009 21:50:49 +0900 | From | Tejun Heo <> | Subject | Re: [PATCH 8/8] blk-map: reimplement blk_rq_map_user() using blk_rq_map_user_iov() |
| |
FUJITA Tomonori wrote: >> * Because each call to bio_map/copy_user() is independent, segment >> limit check was done only per each bio, so it was possible to create >> requests which are larger than the driver and hardware limits, which >> could lead to disastrous outcome. > > What do you mean? blk_rq_append_bio properly checks the segment and > limit, I think.
Right, ll_back_merge_fn() does that. Sorry about that.
>> * Layers under FS may call blk_rq_map*() functions during request >> processing. Under severe memory pressure and with enough bad luck, >> this can lead to deadlock. As fs bvec pool is quite small, the >> possibility isn't completely theoretical. >> >> This patch reimplement blk_rq_map_user() in terms of >> blk_rq_map_user_iov() which doesn't support multi-bio mappping and >> drop multi bio handling from blk_rq_unmap_user(). Note that with the >> previous patch to remove bio max size limit and to add null mapping >> support to blk_rq_map_user_iov(), this change doesn't remove any >> functionality. > > I don't think that we can drop multi bio handling from > blk_rq_unmap_user(). It may make some users angry. Mike Christie added > it because it was necessary.
The only user of blk_rq_append_bio() is scsi_lib.c. Is Mike Christie's code chaining bio's directly into rq?
Thanks.
-- tejun
| |