Re: [PATCH 1/2] blkdev: fix merge_bvec_fn return value checks
From: Jens Axboe
Date: Wed Mar 03 2010 - 15:07:59 EST
On Wed, Mar 03 2010, Dmitry Monakhov wrote:
> Mike Snitzer <snitzer@xxxxxxxxxx> writes:
> > Linux has all sorts of internal interfaces that are "odd"... the current
> > 'q->merge_bvec_fn' interface included. But odd is not a problem (nor is
> > it "broken") unless you make changes that don't consider how the current
> > interface is defined.
> Ok. then cant you please explain more historical questions
> 1) Why bio_add_page() can not add less data than requested?
> Seems that it doesn't make caller's code much complicate
> Off course barrier bio is special case. I don't consider it here.
Because the caller may not expect that, a partial add may not make any
sense to the caller. The bio code obviously doesn't care. And it
certainly could complicate the caller a lot, if they need to now issue
and wait for several bio's instead of just a single one. Now a single
completion queue and wait_for_completion() is not enough.
> 2) What statement "bio_add_page() must accept at least one page"
> exactly means?
> IMHO this means that bio_add_page() must accept at least
> one page with len (PAGE_SIZE - offset). Or more restricted
> statemnt that first bio_add_page() must be always successfull.
It's really 'first add must succeed', the restriction being that you
cannot rely on that first add being more than a single page. So the rule
is that you must accept at least a page at any offset if the bio is
currently empty, since we know that a page is typically our IO
> But currently in some places this rule treated as what all bio
> which has size less whan PAGE_SIZE are accepted. And in x86 such
> bio may has up to 8 pages/bvecs.
Not sure I follow what you are trying to say here.
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/