Files
msm-5.15/include/linux
NeilBrown fbbaf700e7 block: trace completion of all bios.
Currently only dm and md/raid5 bios trigger
trace_block_bio_complete().  Now that we have bio_chain() and
bio_inc_remaining(), it is not possible, in general, for a driver to
know when the bio is really complete.  Only bio_endio() knows that.

So move the trace_block_bio_complete() call to bio_endio().

Now trace_block_bio_complete() pairs with trace_block_bio_queue().
Any bio for which a 'queue' event is traced, will subsequently
generate a 'complete' event.

There are a few cases where completion tracing is not wanted.
1/ If blk_update_request() has already generated a completion
   trace event at the 'request' level, there is no point generating
   one at the bio level too.  In this case the bi_sector and bi_size
   will have changed, so the bio level event would be wrong

2/ If the bio hasn't actually been queued yet, but is being aborted
   early, then a trace event could be confusing.  Some filesystems
   call bio_endio() but do not want tracing.

3/ The bio_integrity code interposes itself by replacing bi_end_io,
   then restoring it and calling bio_endio() again.  This would produce
   two identical trace events if left like that.

To handle these, we introduce a flag BIO_TRACE_COMPLETION and only
produce the trace event when this is set.
We address point 1 above by clearing the flag in blk_update_request().
We address point 2 above by only setting the flag when
generic_make_request() is called.
We address point 3 above by clearing the flag after generating a
completion event.

When bio_split() is used on a bio, particularly in blk_queue_split(),
there is an extra complication.  A new bio is split off the front, and
may be handle directly without going through generic_make_request().
The old bio, which has been advanced, is passed to
generic_make_request(), so it will trigger a trace event a second
time.
Probably the best result when a split happens is to see a single
'queue' event for the whole bio, then multiple 'complete' events - one
for each component.  To achieve this was can:
- copy the BIO_TRACE_COMPLETION flag to the new bio in bio_split()
- avoid generating a 'queue' event if BIO_TRACE_COMPLETION is already set.
This way, the split-off bio won't create a queue event, the original
won't either even if it re-submitted to generic_make_request(),
but both will produce completion events, each for their own range.

So if generic_make_request() is called (which generates a QUEUED
event), then bi_endio() will create a single COMPLETE event for each
range that the bio is split into, unless the driver has explicitly
requested it not to.

Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-04-07 09:40:52 -06:00
..
2017-03-07 14:30:38 +01:00
2017-01-24 12:37:43 -08:00
2017-03-01 09:50:58 -08:00
2016-12-22 22:58:37 -05:00
2016-10-19 14:34:36 -04:00
2017-02-10 15:52:24 -05:00
2017-04-05 09:40:15 -06:00
2017-01-25 13:17:47 -05:00
2016-12-08 13:31:11 -05:00
2016-10-25 11:08:28 +08:00
2016-12-27 14:52:47 -05:00
2016-12-08 16:37:33 -08:00
2017-02-24 17:46:55 -08:00
2017-02-04 00:47:59 +01:00
2016-12-05 19:01:16 -05:00
2016-10-28 08:48:16 -06:00
2017-02-27 10:07:47 -08:00
2016-12-05 19:01:16 -05:00
2017-03-12 23:51:34 -07:00
2016-12-25 17:21:22 +01:00
2017-02-11 20:59:41 -05:00
2016-09-14 09:18:09 -06:00
2017-01-05 15:01:55 -06:00
2017-02-01 09:13:45 +01:00
2016-12-12 18:55:06 -08:00
2016-12-25 17:21:23 +01:00
2017-02-24 17:46:57 -08:00
2016-09-27 12:33:47 +02:00
2016-12-06 11:05:46 +01:00
2017-01-12 16:48:26 -05:00
2017-03-01 09:50:58 -08:00
2016-11-16 18:32:02 -05:00
2016-12-12 18:55:07 -08:00
2016-12-06 10:17:03 +02:00
2017-03-02 08:56:04 -07:00
2016-10-31 16:18:30 -04:00
2016-10-14 11:36:59 -07:00
2016-09-27 21:52:00 -04:00
2016-11-15 16:34:27 -08:00
2017-02-13 21:44:09 -05:00
2017-02-27 18:43:46 -08:00
2017-01-09 16:07:38 -05:00
2016-10-05 18:23:36 -04:00
2017-02-03 11:19:34 -05:00
2016-12-25 17:21:22 +01:00
2017-01-10 18:31:55 -08:00
2017-02-03 10:17:02 +01:00
2016-12-09 22:12:21 -05:00
2017-02-10 16:34:17 +00:00
2016-12-12 18:55:08 -08:00
2017-01-11 09:21:41 +01:00
2017-02-02 15:22:18 -05:00