public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Bart Van Assche <bvanassche@acm.org>, Jens Axboe <axboe@kernel.dk>
Cc: Christoph Hellwig <hch@infradead.org>,
	Christoph Hellwig <hch@lst.de>, Ming Lei <ming.lei@redhat.com>,
	Hannes Reinecke <hare@suse.com>,
	linux-block@vger.kernel.org
Subject: Re: [PATCH] block: Document the bio splitting functions
Date: Tue, 2 Jul 2019 09:39:46 +0200	[thread overview]
Message-ID: <febb2570-5b5f-2283-c0af-784ef4d6475e@suse.de> (raw)
In-Reply-To: <20190701162328.216266-1-bvanassche@acm.org>

On 7/1/19 6:23 PM, Bart Van Assche wrote:
> Since what the bio splitting functions do is nontrivial, document these
> functions.
> 
> Cc: Christoph Hellwig <hch@infradead.org>
> Cc: Ming Lei <ming.lei@redhat.com>
> Cc: Hannes Reinecke <hare@suse.com>
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
> ---
>  block/blk-merge.c | 35 +++++++++++++++++++++++++++++++++++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/block/blk-merge.c b/block/blk-merge.c
> index 1ea00da12ca3..038eaee4438a 100644
> --- a/block/blk-merge.c
> +++ b/block/blk-merge.c
> @@ -192,6 +192,23 @@ static bool bvec_split_segs(const struct request_queue *q,
>  	return !!len;
>  }
>  
> +/**
> + * blk_bio_segment_split - split a bio in two bios
> + * @q:    [in] request queue pointer
> + * @bio:  [in] bio to be split
> + * @bs:	  [in] bio set to allocate the clone from
> + * @segs: [out] number of segments in the bio with the first half of the sectors
> + *
> + * Clones @bio, updates the bi_iter of the clone to represent the first sectors
> + * of @bio and updates @bio->bi_iter to represent the remaining sectors. The
> + * following is guaranteed for the cloned bio:
> + * - That it has at most get_max_io_size(@q, @bio) sectors.
> + * - That it has at most queue_max_segments(@q) segments.
> + *
> + * Except for discard requests the cloned bio will point at the bi_io_vec of
> + * the original bio. It is the responsibility of the caller to ensure that the
> + * original bio is not freed before the cloned bio.
> + */
>  static struct bio *blk_bio_segment_split(struct request_queue *q,
>  					 struct bio *bio,
>  					 struct bio_set *bs,
> @@ -248,6 +265,16 @@ static struct bio *blk_bio_segment_split(struct request_queue *q,
>  	return bio_split(bio, sectors, GFP_NOIO, bs);
>  }
>  
> +/**
> + * __blk_queue_split - split a bio and submit the second half
> + * @q:       [in] request queue pointer
> + * @bio:     [in, out] bio to be split
> + * @nr_segs: [out] number of segments in the first bio
> + *
> + * Splits a bio into two bios, chains the two bios, submits the second half
> + * and stores a pointer to the first half in *@bio. If the second bio is still
> + * too big it will be split by a recursive call to this function.
> + */
>  void __blk_queue_split(struct request_queue *q, struct bio **bio,
>  		unsigned int *nr_segs)
>  {
> @@ -292,6 +319,14 @@ void __blk_queue_split(struct request_queue *q, struct bio **bio,
>  	}
>  }
>  
> +/**
> + * blk_queue_split - split a bio and submit the second half
> + * @q:   [in] request queue pointer
> + * @bio: [in, out] bio to be split
> + *
> + * Splits a bio into two bios, chains the two bios, submits the second half
> + * and stores a pointer to the first half in *@bio.
> + */
>  void blk_queue_split(struct request_queue *q, struct bio **bio)
>  {
>  	unsigned int nr_segs;
> 
Could you add a reference to the bio_set in those descriptions, too?
It's really non-obvious that 'split' will reference the bio_set of the
queue, and hence the queue _must not_ go away while the bio is allocated.
This becomes especially tricky if the bio is remapped to another queue
later on, as then we'll lose the reference to the original queue, and
have no idea that suddenly we have a bio with references to _two_
request queues.

Maybe we should even add a warning somewhere...

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare@suse.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)

  reply	other threads:[~2019-07-02  7:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-01 16:23 [PATCH] block: Document the bio splitting functions Bart Van Assche
2019-07-02  7:39 ` Hannes Reinecke [this message]
2019-07-03 15:14   ` Bart Van Assche
2019-07-03  5:52 ` Minwoo Im

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=febb2570-5b5f-2283-c0af-784ef4d6475e@suse.de \
    --to=hare@suse.de \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=hare@suse.com \
    --cc=hch@infradead.org \
    --cc=hch@lst.de \
    --cc=linux-block@vger.kernel.org \
    --cc=ming.lei@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox