2019-04-30 14:42:39 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-09-04 15:41:16 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-05-07 16:19:08 -07:00
|
|
|
|
2012-03-05 13:15:27 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-16 23:57:37 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-03-05 13:15:27 -08:00
|
|
|
|
2019-07-01 14:09:15 +09:00
|
|
|
|
2020-03-18 11:43:36 +08:00
|
|
|
|
block: Inline encryption support for blk-mq
We must have some way of letting a storage device driver know what
encryption context it should use for en/decrypting a request. However,
it's the upper layers (like the filesystem/fscrypt) that know about and
manages encryption contexts. As such, when the upper layer submits a bio
to the block layer, and this bio eventually reaches a device driver with
support for inline encryption, the device driver will need to have been
told the encryption context for that bio.
We want to communicate the encryption context from the upper layer to the
storage device along with the bio, when the bio is submitted to the block
layer. To do this, we add a struct bio_crypt_ctx to struct bio, which can
represent an encryption context (note that we can't use the bi_private
field in struct bio to do this because that field does not function to pass
information across layers in the storage stack). We also introduce various
functions to manipulate the bio_crypt_ctx and make the bio/request merging
logic aware of the bio_crypt_ctx.
We also make changes to blk-mq to make it handle bios with encryption
contexts. blk-mq can merge many bios into the same request. These bios need
to have contiguous data unit numbers (the necessary changes to blk-merge
are also made to ensure this) - as such, it suffices to keep the data unit
number of just the first bio, since that's all a storage driver needs to
infer the data unit number to use for each data block in each bio in a
request. blk-mq keeps track of the encryption context to be used for all
the bios in a request with the request's rq_crypt_ctx. When the first bio
is added to an empty request, blk-mq will program the encryption context
of that bio into the request_queue's keyslot manager, and store the
returned keyslot in the request's rq_crypt_ctx. All the functions to
operate on encryption contexts are in blk-crypto.c.
Upper layers only need to call bio_crypt_set_ctx with the encryption key,
algorithm and data_unit_num; they don't have to worry about getting a
keyslot for each encryption context, as blk-mq/blk-crypto handles that.
Blk-crypto also makes it possible for request-based layered devices like
dm-rq to make use of inline encryption hardware by cloning the
rq_crypt_ctx and programming a keyslot in the new request_queue when
necessary.
Note that any user of the block layer can submit bios with an
encryption context, such as filesystems, device-mapper targets, etc.
Signed-off-by: Satya Tangirala <satyat@google.com>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-05-14 00:37:18 +00:00
|
|
|
|
2021-01-11 11:05:52 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
tracing/events: convert block trace points to TRACE_EVENT()
TRACE_EVENT is a more generic way to define tracepoints. Doing so adds
these new capabilities to this tracepoint:
- zero-copy and per-cpu splice() tracing
- binary tracing without printf overhead
- structured logging records exposed under /debug/tracing/events
- trace events embedded in function tracer output and other plugins
- user-defined, per tracepoint filter expressions
...
Cons:
- no dev_t info for the output of plug, unplug_timer and unplug_io events.
no dev_t info for getrq and sleeprq events if bio == NULL.
no dev_t info for rq_abort,...,rq_requeue events if rq->rq_disk == NULL.
This is mainly because we can't get the deivce from a request queue.
But this may change in the future.
- A packet command is converted to a string in TP_assign, not TP_print.
While blktrace do the convertion just before output.
Since pc requests should be rather rare, this is not a big issue.
- In blktrace, an event can have 2 different print formats, but a TRACE_EVENT
has a unique format, which means we have some unused data in a trace entry.
The overhead is minimized by using __dynamic_array() instead of __array().
I've benchmarked the ioctl blktrace vs the splice based TRACE_EVENT tracing:
dd dd + ioctl blktrace dd + TRACE_EVENT (splice)
1 7.36s, 42.7 MB/s 7.50s, 42.0 MB/s 7.41s, 42.5 MB/s
2 7.43s, 42.3 MB/s 7.48s, 42.1 MB/s 7.43s, 42.4 MB/s
3 7.38s, 42.6 MB/s 7.45s, 42.2 MB/s 7.41s, 42.5 MB/s
So the overhead of tracing is very small, and no regression when using
those trace events vs blktrace.
And the binary output of TRACE_EVENT is much smaller than blktrace:
# ls -l -h
-rw-r--r-- 1 root root 8.8M 06-09 13:24 sda.blktrace.0
-rw-r--r-- 1 root root 195K 06-09 13:24 sda.blktrace.1
-rw-r--r-- 1 root root 2.7M 06-09 13:25 trace_splice.out
Following are some comparisons between TRACE_EVENT and blktrace:
plug:
kjournald-480 [000] 303.084981: block_plug: [kjournald]
kjournald-480 [000] 303.084981: 8,0 P N [kjournald]
unplug_io:
kblockd/0-118 [000] 300.052973: block_unplug_io: [kblockd/0] 1
kblockd/0-118 [000] 300.052974: 8,0 U N [kblockd/0] 1
remap:
kjournald-480 [000] 303.085042: block_remap: 8,0 W 102736992 + 8 <- (8,8) 33384
kjournald-480 [000] 303.085043: 8,0 A W 102736992 + 8 <- (8,8) 33384
bio_backmerge:
kjournald-480 [000] 303.085086: block_bio_backmerge: 8,0 W 102737032 + 8 [kjournald]
kjournald-480 [000] 303.085086: 8,0 M W 102737032 + 8 [kjournald]
getrq:
kjournald-480 [000] 303.084974: block_getrq: 8,0 W 102736984 + 8 [kjournald]
kjournald-480 [000] 303.084975: 8,0 G W 102736984 + 8 [kjournald]
bash-2066 [001] 1072.953770: 8,0 G N [bash]
bash-2066 [001] 1072.953773: block_getrq: 0,0 N 0 + 0 [bash]
rq_complete:
konsole-2065 [001] 300.053184: block_rq_complete: 8,0 W () 103669040 + 16 [0]
konsole-2065 [001] 300.053191: 8,0 C W 103669040 + 16 [0]
ksoftirqd/1-7 [001] 1072.953811: 8,0 C N (5a 00 08 00 00 00 00 00 24 00) [0]
ksoftirqd/1-7 [001] 1072.953813: block_rq_complete: 0,0 N (5a 00 08 00 00 00 00 00 24 00) 0 + 0 [0]
rq_insert:
kjournald-480 [000] 303.084985: block_rq_insert: 8,0 W 0 () 102736984 + 8 [kjournald]
kjournald-480 [000] 303.084986: 8,0 I W 102736984 + 8 [kjournald]
Changelog from v2 -> v3:
- use the newly introduced __dynamic_array().
Changelog from v1 -> v2:
- use __string() instead of __array() to minimize the memory required
to store hex dump of rq->cmd().
- support large pc requests.
- add missing blk_fill_rwbs_rq() in block_rq_requeue TRACE_EVENT.
- some cleanups.
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
LKML-Reference: <4A2DF669.5070905@cn.fujitsu.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2009-06-09 13:43:05 +08:00
|
|
|
|
blk-throttle: add a simple idle detection
A cgroup gets assigned a low limit, but the cgroup could never dispatch
enough IO to cross the low limit. In such case, the queue state machine
will remain in LIMIT_LOW state and all other cgroups will be throttled
according to low limit. This is unfair for other cgroups. We should
treat the cgroup idle and upgrade the state machine to lower state.
We also have a downgrade logic. If the state machine upgrades because of
cgroup idle (real idle), the state machine will downgrade soon as the
cgroup is below its low limit. This isn't what we want. A more
complicated case is cgroup isn't idle when queue is in LIMIT_LOW. But
when queue gets upgraded to lower state, other cgroups could dispatch
more IO and this cgroup can't dispatch enough IO, so the cgroup is below
its low limit and looks like idle (fake idle). In this case, the queue
should downgrade soon. The key to determine if we should do downgrade is
to detect if cgroup is truely idle.
Unfortunately it's very hard to determine if a cgroup is real idle. This
patch uses the 'think time check' idea from CFQ for the purpose. Please
note, the idea doesn't work for all workloads. For example, a workload
with io depth 8 has disk utilization 100%, hence think time is 0, eg,
not idle. But the workload can run higher bandwidth with io depth 16.
Compared to io depth 16, the io depth 8 workload is idle. We use the
idea to roughly determine if a cgroup is idle.
We treat a cgroup idle if its think time is above a threshold (by
default 1ms for SSD and 100ms for HD). The idea is think time above the
threshold will start to harm performance. HD is much slower so a longer
think time is ok.
The patch (and the latter patches) uses 'unsigned long' to track time.
We convert 'ns' to 'us' with 'ns >> 10'. This is fast but loses
precision, should not a big deal.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-27 10:51:41 -07:00
|
|
|
|
2018-07-03 11:15:00 -04:00
|
|
|
|
2022-02-11 18:11:49 +08:00
|
|
|
|
2008-11-26 11:59:56 +01:00
|
|
|
|
2021-03-08 11:37:47 -07:00
|
|
|
|
2021-12-01 16:19:18 -07:00
|
|
|
|
2021-03-08 11:37:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-02-02 18:19:23 +01:00
|
|
|
|
2021-02-02 18:19:20 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-02-02 18:19:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-11 12:01:37 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-02-02 18:19:20 +01:00
|
|
|
|
2021-02-02 18:19:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-11 12:01:37 +01:00
|
|
|
|
2021-02-02 18:19:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-05-08 21:33:52 -04:00
|
|
|
|
2012-09-06 15:35:01 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-12-10 15:35:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-11 11:05:52 +08:00
|
|
|
|
2008-12-10 15:35:05 +01:00
|
|
|
|
2021-01-11 11:05:52 +08:00
|
|
|
|
2008-12-10 15:35:05 +01:00
|
|
|
|
2021-01-11 11:05:52 +08:00
|
|
|
|
2008-12-10 15:35:05 +01:00
|
|
|
|
2021-01-11 11:05:52 +08:00
|
|
|
|
|
|
|
|
|
2008-12-10 15:35:05 +01:00
|
|
|
|
2021-01-11 11:05:52 +08:00
|
|
|
|
|
|
|
|
|
2021-10-12 13:12:22 +02:00
|
|
|
|
|
|
|
|
|
2021-01-11 11:05:52 +08:00
|
|
|
|
|
|
|
|
|
2008-12-10 15:35:05 +01:00
|
|
|
|
2021-01-11 11:05:52 +08:00
|
|
|
|
|
|
|
|
|
2008-12-10 15:35:05 +01:00
|
|
|
|
2021-01-11 11:05:52 +08:00
|
|
|
|
|
|
|
|
|
2008-12-10 15:35:05 +01:00
|
|
|
|
2021-01-11 11:05:52 +08:00
|
|
|
|
2008-12-10 15:35:05 +01:00
|
|
|
|
2021-01-11 11:05:52 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-10 15:35:05 +01:00
|
|
|
|
2021-01-11 11:05:52 +08:00
|
|
|
|
|
|
|
|
|
2021-01-11 11:05:54 +08:00
|
|
|
|
2021-01-11 11:05:52 +08:00
|
|
|
|
2008-12-10 15:35:05 +01:00
|
|
|
|
2021-01-11 11:05:52 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-10 15:35:05 +01:00
|
|
|
|
2021-01-11 11:05:52 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-10 15:35:05 +01:00
|
|
|
|
2021-01-11 11:05:52 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-10 15:35:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-11 11:05:52 +08:00
|
|
|
|
2008-12-10 15:35:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-11 11:05:52 +08:00
|
|
|
|
2008-12-10 15:35:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-11 11:05:52 +08:00
|
|
|
|
|
|
|
|
|
2008-12-10 15:35:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-11 11:05:52 +08:00
|
|
|
|
|
|
|
|
|
2008-12-10 15:35:05 +01:00
|
|
|
|
2021-01-11 11:05:52 +08:00
|
|
|
|
2008-12-10 15:35:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-02-02 18:19:29 +01:00
|
|
|
|
2008-06-30 20:04:41 +02:00
|
|
|
|
2021-10-12 18:17:57 +02:00
|
|
|
|
2016-07-19 11:28:42 +02:00
|
|
|
|
2021-03-11 12:01:37 +01:00
|
|
|
|
2012-10-12 15:29:33 -07:00
|
|
|
|
2021-02-02 18:19:29 +01:00
|
|
|
|
|
|
|
|
|
2008-12-10 15:35:05 +01:00
|
|
|
|
|
|
|
|
|
2021-02-02 18:19:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-10 15:35:05 +01:00
|
|
|
|
|
|
|
|
|
2021-02-02 18:19:29 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-02-02 18:19:29 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-02-02 18:19:29 +01:00
|
|
|
|
2008-12-11 11:53:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-02-02 18:19:29 +01:00
|
|
|
|
|
|
|
|
|
2008-12-11 11:53:43 +01:00
|
|
|
|
2021-02-02 18:19:29 +01:00
|
|
|
|
2008-12-11 11:53:43 +01:00
|
|
|
|
|
|
|
|
|
2021-02-02 18:19:22 +01:00
|
|
|
|
|
|
|
|
|
2021-03-11 12:01:37 +01:00
|
|
|
|
2008-12-11 11:53:43 +01:00
|
|
|
|
2021-03-11 12:01:37 +01:00
|
|
|
|
2021-02-02 18:19:22 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-02-02 18:19:21 +01:00
|
|
|
|
2021-02-02 18:19:29 +01:00
|
|
|
|
2021-02-02 18:19:22 +01:00
|
|
|
|
2021-03-11 12:01:37 +01:00
|
|
|
|
2008-12-11 11:53:43 +01:00
|
|
|
|
|
|
|
|
|
2021-02-02 18:19:22 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2017-06-28 15:30:13 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2020-06-27 09:31:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-12-05 10:09:01 +08:00
|
|
|
|
|
|
|
|
|
block: Inline encryption support for blk-mq
We must have some way of letting a storage device driver know what
encryption context it should use for en/decrypting a request. However,
it's the upper layers (like the filesystem/fscrypt) that know about and
manages encryption contexts. As such, when the upper layer submits a bio
to the block layer, and this bio eventually reaches a device driver with
support for inline encryption, the device driver will need to have been
told the encryption context for that bio.
We want to communicate the encryption context from the upper layer to the
storage device along with the bio, when the bio is submitted to the block
layer. To do this, we add a struct bio_crypt_ctx to struct bio, which can
represent an encryption context (note that we can't use the bi_private
field in struct bio to do this because that field does not function to pass
information across layers in the storage stack). We also introduce various
functions to manipulate the bio_crypt_ctx and make the bio/request merging
logic aware of the bio_crypt_ctx.
We also make changes to blk-mq to make it handle bios with encryption
contexts. blk-mq can merge many bios into the same request. These bios need
to have contiguous data unit numbers (the necessary changes to blk-merge
are also made to ensure this) - as such, it suffices to keep the data unit
number of just the first bio, since that's all a storage driver needs to
infer the data unit number to use for each data block in each bio in a
request. blk-mq keeps track of the encryption context to be used for all
the bios in a request with the request's rq_crypt_ctx. When the first bio
is added to an empty request, blk-mq will program the encryption context
of that bio into the request_queue's keyslot manager, and store the
returned keyslot in the request's rq_crypt_ctx. All the functions to
operate on encryption contexts are in blk-crypto.c.
Upper layers only need to call bio_crypt_set_ctx with the encryption key,
algorithm and data_unit_num; they don't have to worry about getting a
keyslot for each encryption context, as blk-mq/blk-crypto handles that.
Blk-crypto also makes it possible for request-based layered devices like
dm-rq to make use of inline encryption hardware by cloning the
rq_crypt_ctx and programming a keyslot in the new request_queue when
necessary.
Note that any user of the block layer can submit bios with an
encryption context, such as filesystems, device-mapper targets, etc.
Signed-off-by: Satya Tangirala <satyat@google.com>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-05-14 00:37:18 +00:00
|
|
|
|
|
|
|
|
|
2012-09-06 15:35:00 -07:00
|
|
|
|
2017-06-28 15:30:13 -06:00
|
|
|
|
2008-06-30 20:04:41 +02:00
|
|
|
|
2012-09-06 15:35:00 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-06 08:12:27 +02:00
|
|
|
|
2012-09-06 15:35:00 -07:00
|
|
|
|
2022-04-06 08:12:27 +02:00
|
|
|
|
2012-09-06 15:35:00 -07:00
|
|
|
|
2022-04-06 08:12:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-09-06 15:16:42 -07:00
|
|
|
|
|
|
|
|
|
2017-06-28 15:30:13 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-01-24 10:11:06 +01:00
|
|
|
|
2022-07-14 11:06:32 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-08-11 09:20:04 -06:00
|
|
|
|
2022-01-24 10:11:06 +01:00
|
|
|
|
|
|
|
|
|
2021-08-11 09:20:04 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-01-24 10:11:06 +01:00
|
|
|
|
|
|
|
|
|
2021-08-11 09:20:04 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-17 16:15:18 -06:00
|
|
|
|
2015-04-17 16:23:59 -06:00
|
|
|
|
2021-10-12 13:12:24 +02:00
|
|
|
|
2016-11-22 08:57:21 -07:00
|
|
|
|
|
|
|
|
|
2021-08-11 09:20:04 -06:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-09-26 16:19:21 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-09-06 15:34:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-01-24 10:11:07 +01:00
|
|
|
|
|
|
|
|
|
2012-09-06 15:34:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-14 11:06:32 -07:00
|
|
|
|
2012-09-06 15:34:58 -07:00
|
|
|
|
2017-06-28 15:30:13 -06:00
|
|
|
|
2012-09-06 15:34:58 -07:00
|
|
|
|
2015-04-17 16:15:18 -06:00
|
|
|
|
2022-01-24 10:11:07 +01:00
|
|
|
|
2022-02-04 08:19:34 +01:00
|
|
|
|
|
|
|
|
|
2022-01-24 10:11:07 +01:00
|
|
|
|
2012-09-06 15:34:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-03-11 17:34:51 +01:00
|
|
|
|
2013-11-23 18:34:15 -08:00
|
|
|
|
2015-07-20 15:29:37 +02:00
|
|
|
|
|
|
|
|
|
block: only update parent bi_status when bio fail
For multiple split bios, if one of the bio is fail, the whole
should return error to application. But we found there is a race
between bio_integrity_verify_fn and bio complete, which return
io success to application after one of the bio fail. The race as
following:
split bio(READ) kworker
nvme_complete_rq
blk_update_request //split error=0
bio_endio
bio_integrity_endio
queue_work(kintegrityd_wq, &bip->bip_work);
bio_integrity_verify_fn
bio_endio //split bio
__bio_chain_endio
if (!parent->bi_status)
<interrupt entry>
nvme_irq
blk_update_request //parent error=7
req_bio_endio
bio->bi_status = 7 //parent bio
<interrupt exit>
parent->bi_status = 0
parent->bi_end_io() // return bi_status=0
The bio has been split as two: split and parent. When split
bio completed, it depends on kworker to do endio, while
bio_integrity_verify_fn have been interrupted by parent bio
complete irq handler. Then, parent bio->bi_status which have
been set in irq handler will overwrite by kworker.
In fact, even without the above race, we also need to conside
the concurrency beteen mulitple split bio complete and update
the same parent bi_status. Normally, multiple split bios will
be issued to the same hctx and complete from the same irq
vector. But if we have updated queue map between multiple split
bios, these bios may complete on different hw queue and different
irq vector. Then the concurrency update parent bi_status may
cause the final status error.
Suggested-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Yufen Yu <yuyufen@huawei.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Link: https://lore.kernel.org/r/20210331115359.1125679-1-yuyufen@huawei.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-03-31 07:53:59 -04:00
|
|
|
|
2017-06-03 09:38:06 +02:00
|
|
|
|
2013-11-23 18:34:15 -08:00
|
|
|
|
2016-03-11 17:34:51 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-23 18:34:15 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-20 16:03:31 -07:00
|
|
|
|
2020-08-27 07:51:44 +02:00
|
|
|
|
2013-11-23 18:34:15 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-17 16:15:18 -06:00
|
|
|
|
2013-11-23 18:34:15 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-01-24 10:11:02 +01:00
|
|
|
|
2022-07-14 11:06:32 -07:00
|
|
|
|
2022-01-24 10:11:01 +01:00
|
|
|
|
2022-01-24 10:11:05 +01:00
|
|
|
|
2022-01-24 10:11:02 +01:00
|
|
|
|
2022-01-24 10:11:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
block: Avoid deadlocks with bio allocation by stacking drivers
Previously, if we ever try to allocate more than once from the same bio
set while running under generic_make_request() (i.e. a stacking block
driver), we risk deadlock.
This is because of the code in generic_make_request() that converts
recursion to iteration; any bios we submit won't actually be submitted
(so they can complete and eventually be freed) until after we return -
this means if we allocate a second bio, we're blocking the first one
from ever being freed.
Thus if enough threads call into a stacking block driver at the same
time with bios that need multiple splits, and the bio_set's reserve gets
used up, we deadlock.
This can be worked around in the driver code - we could check if we're
running under generic_make_request(), then mask out __GFP_WAIT when we
go to allocate a bio, and if the allocation fails punt to workqueue and
retry the allocation.
But this is tricky and not a generic solution. This patch solves it for
all users by inverting the previously described technique. We allocate a
rescuer workqueue for each bio_set, and then in the allocation code if
there are bios on current->bio_list we would be blocking, we punt them
to the rescuer workqueue to be submitted.
This guarantees forward progress for bio allocations under
generic_make_request() provided each bio is submitted before allocating
the next, and provided the bios are freed after they complete.
Note that this doesn't do anything for allocation from other mempools.
Instead of allocating per bio data structures from a mempool, code
should use bio_set's front_pad.
Tested it by forcing the rescue codepath to be taken (by disabling the
first GFP_NOWAIT) attempt, and then ran it with bcache (which does a lot
of arbitrary bio splitting) and verified that the rescuer was being
invoked.
Signed-off-by: Kent Overstreet <koverstreet@google.com>
CC: Jens Axboe <axboe@kernel.dk>
Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Muthukumar Ratty <muthur@gmail.com>
2012-09-10 14:33:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-01 10:59:44 +02:00
|
|
|
|
block: Avoid deadlocks with bio allocation by stacking drivers
Previously, if we ever try to allocate more than once from the same bio
set while running under generic_make_request() (i.e. a stacking block
driver), we risk deadlock.
This is because of the code in generic_make_request() that converts
recursion to iteration; any bios we submit won't actually be submitted
(so they can complete and eventually be freed) until after we return -
this means if we allocate a second bio, we're blocking the first one
from ever being freed.
Thus if enough threads call into a stacking block driver at the same
time with bios that need multiple splits, and the bio_set's reserve gets
used up, we deadlock.
This can be worked around in the driver code - we could check if we're
running under generic_make_request(), then mask out __GFP_WAIT when we
go to allocate a bio, and if the allocation fails punt to workqueue and
retry the allocation.
But this is tricky and not a generic solution. This patch solves it for
all users by inverting the previously described technique. We allocate a
rescuer workqueue for each bio_set, and then in the allocation code if
there are bios on current->bio_list we would be blocking, we punt them
to the rescuer workqueue to be submitted.
This guarantees forward progress for bio allocations under
generic_make_request() provided each bio is submitted before allocating
the next, and provided the bios are freed after they complete.
Note that this doesn't do anything for allocation from other mempools.
Instead of allocating per bio data structures from a mempool, code
should use bio_set's front_pad.
Tested it by forcing the rescue codepath to be taken (by disabling the
first GFP_NOWAIT) attempt, and then ran it with bcache (which does a lot
of arbitrary bio splitting) and verified that the rescuer was being
invoked.
Signed-off-by: Kent Overstreet <koverstreet@google.com>
CC: Jens Axboe <axboe@kernel.dk>
Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Muthukumar Ratty <muthur@gmail.com>
2012-09-10 14:33:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-18 14:38:57 +10:00
|
|
|
|
|
|
|
|
|
block: Avoid deadlocks with bio allocation by stacking drivers
Previously, if we ever try to allocate more than once from the same bio
set while running under generic_make_request() (i.e. a stacking block
driver), we risk deadlock.
This is because of the code in generic_make_request() that converts
recursion to iteration; any bios we submit won't actually be submitted
(so they can complete and eventually be freed) until after we return -
this means if we allocate a second bio, we're blocking the first one
from ever being freed.
Thus if enough threads call into a stacking block driver at the same
time with bios that need multiple splits, and the bio_set's reserve gets
used up, we deadlock.
This can be worked around in the driver code - we could check if we're
running under generic_make_request(), then mask out __GFP_WAIT when we
go to allocate a bio, and if the allocation fails punt to workqueue and
retry the allocation.
But this is tricky and not a generic solution. This patch solves it for
all users by inverting the previously described technique. We allocate a
rescuer workqueue for each bio_set, and then in the allocation code if
there are bios on current->bio_list we would be blocking, we punt them
to the rescuer workqueue to be submitted.
This guarantees forward progress for bio allocations under
generic_make_request() provided each bio is submitted before allocating
the next, and provided the bios are freed after they complete.
Note that this doesn't do anything for allocation from other mempools.
Instead of allocating per bio data structures from a mempool, code
should use bio_set's front_pad.
Tested it by forcing the rescue codepath to be taken (by disabling the
first GFP_NOWAIT) attempt, and then ran it with bcache (which does a lot
of arbitrary bio splitting) and verified that the rescuer was being
invoked.
Signed-off-by: Kent Overstreet <koverstreet@google.com>
CC: Jens Axboe <axboe@kernel.dk>
Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Muthukumar Ratty <muthur@gmail.com>
2012-09-10 14:33:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-10 17:00:47 +11:00
|
|
|
|
block: Avoid deadlocks with bio allocation by stacking drivers
Previously, if we ever try to allocate more than once from the same bio
set while running under generic_make_request() (i.e. a stacking block
driver), we risk deadlock.
This is because of the code in generic_make_request() that converts
recursion to iteration; any bios we submit won't actually be submitted
(so they can complete and eventually be freed) until after we return -
this means if we allocate a second bio, we're blocking the first one
from ever being freed.
Thus if enough threads call into a stacking block driver at the same
time with bios that need multiple splits, and the bio_set's reserve gets
used up, we deadlock.
This can be worked around in the driver code - we could check if we're
running under generic_make_request(), then mask out __GFP_WAIT when we
go to allocate a bio, and if the allocation fails punt to workqueue and
retry the allocation.
But this is tricky and not a generic solution. This patch solves it for
all users by inverting the previously described technique. We allocate a
rescuer workqueue for each bio_set, and then in the allocation code if
there are bios on current->bio_list we would be blocking, we punt them
to the rescuer workqueue to be submitted.
This guarantees forward progress for bio allocations under
generic_make_request() provided each bio is submitted before allocating
the next, and provided the bios are freed after they complete.
Note that this doesn't do anything for allocation from other mempools.
Instead of allocating per bio data structures from a mempool, code
should use bio_set's front_pad.
Tested it by forcing the rescue codepath to be taken (by disabling the
first GFP_NOWAIT) attempt, and then ran it with bcache (which does a lot
of arbitrary bio splitting) and verified that the rescuer was being
invoked.
Signed-off-by: Kent Overstreet <koverstreet@google.com>
CC: Jens Axboe <axboe@kernel.dk>
Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Muthukumar Ratty <muthur@gmail.com>
2012-09-10 14:33:46 -07:00
|
|
|
|
2017-03-10 17:00:47 +11:00
|
|
|
|
block: Avoid deadlocks with bio allocation by stacking drivers
Previously, if we ever try to allocate more than once from the same bio
set while running under generic_make_request() (i.e. a stacking block
driver), we risk deadlock.
This is because of the code in generic_make_request() that converts
recursion to iteration; any bios we submit won't actually be submitted
(so they can complete and eventually be freed) until after we return -
this means if we allocate a second bio, we're blocking the first one
from ever being freed.
Thus if enough threads call into a stacking block driver at the same
time with bios that need multiple splits, and the bio_set's reserve gets
used up, we deadlock.
This can be worked around in the driver code - we could check if we're
running under generic_make_request(), then mask out __GFP_WAIT when we
go to allocate a bio, and if the allocation fails punt to workqueue and
retry the allocation.
But this is tricky and not a generic solution. This patch solves it for
all users by inverting the previously described technique. We allocate a
rescuer workqueue for each bio_set, and then in the allocation code if
there are bios on current->bio_list we would be blocking, we punt them
to the rescuer workqueue to be submitted.
This guarantees forward progress for bio allocations under
generic_make_request() provided each bio is submitted before allocating
the next, and provided the bios are freed after they complete.
Note that this doesn't do anything for allocation from other mempools.
Instead of allocating per bio data structures from a mempool, code
should use bio_set's front_pad.
Tested it by forcing the rescue codepath to be taken (by disabling the
first GFP_NOWAIT) attempt, and then ran it with bcache (which does a lot
of arbitrary bio splitting) and verified that the rescuer was being
invoked.
Signed-off-by: Kent Overstreet <koverstreet@google.com>
CC: Jens Axboe <axboe@kernel.dk>
Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Muthukumar Ratty <muthur@gmail.com>
2012-09-10 14:33:46 -07:00
|
|
|
|
2017-03-10 17:00:47 +11:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
block: Avoid deadlocks with bio allocation by stacking drivers
Previously, if we ever try to allocate more than once from the same bio
set while running under generic_make_request() (i.e. a stacking block
driver), we risk deadlock.
This is because of the code in generic_make_request() that converts
recursion to iteration; any bios we submit won't actually be submitted
(so they can complete and eventually be freed) until after we return -
this means if we allocate a second bio, we're blocking the first one
from ever being freed.
Thus if enough threads call into a stacking block driver at the same
time with bios that need multiple splits, and the bio_set's reserve gets
used up, we deadlock.
This can be worked around in the driver code - we could check if we're
running under generic_make_request(), then mask out __GFP_WAIT when we
go to allocate a bio, and if the allocation fails punt to workqueue and
retry the allocation.
But this is tricky and not a generic solution. This patch solves it for
all users by inverting the previously described technique. We allocate a
rescuer workqueue for each bio_set, and then in the allocation code if
there are bios on current->bio_list we would be blocking, we punt them
to the rescuer workqueue to be submitted.
This guarantees forward progress for bio allocations under
generic_make_request() provided each bio is submitted before allocating
the next, and provided the bios are freed after they complete.
Note that this doesn't do anything for allocation from other mempools.
Instead of allocating per bio data structures from a mempool, code
should use bio_set's front_pad.
Tested it by forcing the rescue codepath to be taken (by disabling the
first GFP_NOWAIT) attempt, and then ran it with bcache (which does a lot
of arbitrary bio splitting) and verified that the rescuer was being
invoked.
Signed-off-by: Kent Overstreet <koverstreet@google.com>
CC: Jens Axboe <axboe@kernel.dk>
Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Muthukumar Ratty <muthur@gmail.com>
2012-09-10 14:33:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-03-24 16:35:24 -04:00
|
|
|
|
2022-07-14 11:06:32 -07:00
|
|
|
|
2022-03-24 16:35:24 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2022-01-24 10:11:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-10-16 11:01:00 -07:00
|
|
|
|
2010-01-15 12:05:07 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-01-26 15:52:34 +01:00
|
|
|
|
2012-09-06 15:35:01 -07:00
|
|
|
|
2021-01-26 15:52:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-06 15:35:01 -07:00
|
|
|
|
2021-01-26 15:52:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
block: Avoid deadlocks with bio allocation by stacking drivers
Previously, if we ever try to allocate more than once from the same bio
set while running under generic_make_request() (i.e. a stacking block
driver), we risk deadlock.
This is because of the code in generic_make_request() that converts
recursion to iteration; any bios we submit won't actually be submitted
(so they can complete and eventually be freed) until after we return -
this means if we allocate a second bio, we're blocking the first one
from ever being freed.
Thus if enough threads call into a stacking block driver at the same
time with bios that need multiple splits, and the bio_set's reserve gets
used up, we deadlock.
This can be worked around in the driver code - we could check if we're
running under generic_make_request(), then mask out __GFP_WAIT when we
go to allocate a bio, and if the allocation fails punt to workqueue and
retry the allocation.
But this is tricky and not a generic solution. This patch solves it for
all users by inverting the previously described technique. We allocate a
rescuer workqueue for each bio_set, and then in the allocation code if
there are bios on current->bio_list we would be blocking, we punt them
to the rescuer workqueue to be submitted.
This guarantees forward progress for bio allocations under
generic_make_request() provided each bio is submitted before allocating
the next, and provided the bios are freed after they complete.
Note that this doesn't do anything for allocation from other mempools.
Instead of allocating per bio data structures from a mempool, code
should use bio_set's front_pad.
Tested it by forcing the rescue codepath to be taken (by disabling the
first GFP_NOWAIT) attempt, and then ran it with bcache (which does a lot
of arbitrary bio splitting) and verified that the rescuer was being
invoked.
Signed-off-by: Kent Overstreet <koverstreet@google.com>
CC: Jens Axboe <axboe@kernel.dk>
Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Muthukumar Ratty <muthur@gmail.com>
2012-09-10 14:33:46 -07:00
|
|
|
|
2021-01-26 15:52:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
block: Avoid deadlocks with bio allocation by stacking drivers
Previously, if we ever try to allocate more than once from the same bio
set while running under generic_make_request() (i.e. a stacking block
driver), we risk deadlock.
This is because of the code in generic_make_request() that converts
recursion to iteration; any bios we submit won't actually be submitted
(so they can complete and eventually be freed) until after we return -
this means if we allocate a second bio, we're blocking the first one
from ever being freed.
Thus if enough threads call into a stacking block driver at the same
time with bios that need multiple splits, and the bio_set's reserve gets
used up, we deadlock.
This can be worked around in the driver code - we could check if we're
running under generic_make_request(), then mask out __GFP_WAIT when we
go to allocate a bio, and if the allocation fails punt to workqueue and
retry the allocation.
But this is tricky and not a generic solution. This patch solves it for
all users by inverting the previously described technique. We allocate a
rescuer workqueue for each bio_set, and then in the allocation code if
there are bios on current->bio_list we would be blocking, we punt them
to the rescuer workqueue to be submitted.
This guarantees forward progress for bio allocations under
generic_make_request() provided each bio is submitted before allocating
the next, and provided the bios are freed after they complete.
Note that this doesn't do anything for allocation from other mempools.
Instead of allocating per bio data structures from a mempool, code
should use bio_set's front_pad.
Tested it by forcing the rescue codepath to be taken (by disabling the
first GFP_NOWAIT) attempt, and then ran it with bcache (which does a lot
of arbitrary bio splitting) and verified that the rescuer was being
invoked.
Signed-off-by: Kent Overstreet <koverstreet@google.com>
CC: Jens Axboe <axboe@kernel.dk>
Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Muthukumar Ratty <muthur@gmail.com>
2012-09-10 14:33:46 -07:00
|
|
|
|
2021-01-26 15:52:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
block: Avoid deadlocks with bio allocation by stacking drivers
Previously, if we ever try to allocate more than once from the same bio
set while running under generic_make_request() (i.e. a stacking block
driver), we risk deadlock.
This is because of the code in generic_make_request() that converts
recursion to iteration; any bios we submit won't actually be submitted
(so they can complete and eventually be freed) until after we return -
this means if we allocate a second bio, we're blocking the first one
from ever being freed.
Thus if enough threads call into a stacking block driver at the same
time with bios that need multiple splits, and the bio_set's reserve gets
used up, we deadlock.
This can be worked around in the driver code - we could check if we're
running under generic_make_request(), then mask out __GFP_WAIT when we
go to allocate a bio, and if the allocation fails punt to workqueue and
retry the allocation.
But this is tricky and not a generic solution. This patch solves it for
all users by inverting the previously described technique. We allocate a
rescuer workqueue for each bio_set, and then in the allocation code if
there are bios on current->bio_list we would be blocking, we punt them
to the rescuer workqueue to be submitted.
This guarantees forward progress for bio allocations under
generic_make_request() provided each bio is submitted before allocating
the next, and provided the bios are freed after they complete.
Note that this doesn't do anything for allocation from other mempools.
Instead of allocating per bio data structures from a mempool, code
should use bio_set's front_pad.
Tested it by forcing the rescue codepath to be taken (by disabling the
first GFP_NOWAIT) attempt, and then ran it with bcache (which does a lot
of arbitrary bio splitting) and verified that the rescuer was being
invoked.
Signed-off-by: Kent Overstreet <koverstreet@google.com>
CC: Jens Axboe <axboe@kernel.dk>
Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Muthukumar Ratty <muthur@gmail.com>
2012-09-10 14:33:46 -07:00
|
|
|
|
2022-03-24 16:35:24 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-26 15:52:34 +01:00
|
|
|
|
2012-09-06 15:35:01 -07:00
|
|
|
|
2022-01-24 10:11:03 +01:00
|
|
|
|
2022-07-14 11:06:32 -07:00
|
|
|
|
2017-03-23 13:24:55 +03:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
block: Avoid deadlocks with bio allocation by stacking drivers
Previously, if we ever try to allocate more than once from the same bio
set while running under generic_make_request() (i.e. a stacking block
driver), we risk deadlock.
This is because of the code in generic_make_request() that converts
recursion to iteration; any bios we submit won't actually be submitted
(so they can complete and eventually be freed) until after we return -
this means if we allocate a second bio, we're blocking the first one
from ever being freed.
Thus if enough threads call into a stacking block driver at the same
time with bios that need multiple splits, and the bio_set's reserve gets
used up, we deadlock.
This can be worked around in the driver code - we could check if we're
running under generic_make_request(), then mask out __GFP_WAIT when we
go to allocate a bio, and if the allocation fails punt to workqueue and
retry the allocation.
But this is tricky and not a generic solution. This patch solves it for
all users by inverting the previously described technique. We allocate a
rescuer workqueue for each bio_set, and then in the allocation code if
there are bios on current->bio_list we would be blocking, we punt them
to the rescuer workqueue to be submitted.
This guarantees forward progress for bio allocations under
generic_make_request() provided each bio is submitted before allocating
the next, and provided the bios are freed after they complete.
Note that this doesn't do anything for allocation from other mempools.
Instead of allocating per bio data structures from a mempool, code
should use bio_set's front_pad.
Tested it by forcing the rescue codepath to be taken (by disabling the
first GFP_NOWAIT) attempt, and then ran it with bcache (which does a lot
of arbitrary bio splitting) and verified that the rescuer was being
invoked.
Signed-off-by: Kent Overstreet <koverstreet@google.com>
CC: Jens Axboe <axboe@kernel.dk>
Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Muthukumar Ratty <muthur@gmail.com>
2012-09-10 14:33:46 -07:00
|
|
|
|
2009-04-15 19:50:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-01-24 10:11:03 +01:00
|
|
|
|
|
|
|
|
|
2021-01-26 15:52:34 +01:00
|
|
|
|
block: Avoid deadlocks with bio allocation by stacking drivers
Previously, if we ever try to allocate more than once from the same bio
set while running under generic_make_request() (i.e. a stacking block
driver), we risk deadlock.
This is because of the code in generic_make_request() that converts
recursion to iteration; any bios we submit won't actually be submitted
(so they can complete and eventually be freed) until after we return -
this means if we allocate a second bio, we're blocking the first one
from ever being freed.
Thus if enough threads call into a stacking block driver at the same
time with bios that need multiple splits, and the bio_set's reserve gets
used up, we deadlock.
This can be worked around in the driver code - we could check if we're
running under generic_make_request(), then mask out __GFP_WAIT when we
go to allocate a bio, and if the allocation fails punt to workqueue and
retry the allocation.
But this is tricky and not a generic solution. This patch solves it for
all users by inverting the previously described technique. We allocate a
rescuer workqueue for each bio_set, and then in the allocation code if
there are bios on current->bio_list we would be blocking, we punt them
to the rescuer workqueue to be submitted.
This guarantees forward progress for bio allocations under
generic_make_request() provided each bio is submitted before allocating
the next, and provided the bios are freed after they complete.
Note that this doesn't do anything for allocation from other mempools.
Instead of allocating per bio data structures from a mempool, code
should use bio_set's front_pad.
Tested it by forcing the rescue codepath to be taken (by disabling the
first GFP_NOWAIT) attempt, and then ran it with bcache (which does a lot
of arbitrary bio splitting) and verified that the rescuer was being
invoked.
Signed-off-by: Kent Overstreet <koverstreet@google.com>
CC: Jens Axboe <axboe@kernel.dk>
Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Muthukumar Ratty <muthur@gmail.com>
2012-09-10 14:33:46 -07:00
|
|
|
|
2022-03-24 16:35:24 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-26 15:52:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-05-08 21:33:50 -04:00
|
|
|
|
2012-09-06 15:35:01 -07:00
|
|
|
|
2009-04-15 19:50:51 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-01-26 15:52:34 +01:00
|
|
|
|
2022-01-24 10:11:03 +01:00
|
|
|
|
2021-01-26 15:52:34 +01:00
|
|
|
|
2009-02-21 11:16:36 +01:00
|
|
|
|
2022-01-24 10:11:03 +01:00
|
|
|
|
block: Avoid deadlocks with bio allocation by stacking drivers
Previously, if we ever try to allocate more than once from the same bio
set while running under generic_make_request() (i.e. a stacking block
driver), we risk deadlock.
This is because of the code in generic_make_request() that converts
recursion to iteration; any bios we submit won't actually be submitted
(so they can complete and eventually be freed) until after we return -
this means if we allocate a second bio, we're blocking the first one
from ever being freed.
Thus if enough threads call into a stacking block driver at the same
time with bios that need multiple splits, and the bio_set's reserve gets
used up, we deadlock.
This can be worked around in the driver code - we could check if we're
running under generic_make_request(), then mask out __GFP_WAIT when we
go to allocate a bio, and if the allocation fails punt to workqueue and
retry the allocation.
But this is tricky and not a generic solution. This patch solves it for
all users by inverting the previously described technique. We allocate a
rescuer workqueue for each bio_set, and then in the allocation code if
there are bios on current->bio_list we would be blocking, we punt them
to the rescuer workqueue to be submitted.
This guarantees forward progress for bio allocations under
generic_make_request() provided each bio is submitted before allocating
the next, and provided the bios are freed after they complete.
Note that this doesn't do anything for allocation from other mempools.
Instead of allocating per bio data structures from a mempool, code
should use bio_set's front_pad.
Tested it by forcing the rescue codepath to be taken (by disabling the
first GFP_NOWAIT) attempt, and then ran it with bcache (which does a lot
of arbitrary bio splitting) and verified that the rescuer was being
invoked.
Signed-off-by: Kent Overstreet <koverstreet@google.com>
CC: Jens Axboe <axboe@kernel.dk>
Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Muthukumar Ratty <muthur@gmail.com>
2012-09-10 14:33:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-01-24 10:11:03 +01:00
|
|
|
|
block: Avoid deadlocks with bio allocation by stacking drivers
Previously, if we ever try to allocate more than once from the same bio
set while running under generic_make_request() (i.e. a stacking block
driver), we risk deadlock.
This is because of the code in generic_make_request() that converts
recursion to iteration; any bios we submit won't actually be submitted
(so they can complete and eventually be freed) until after we return -
this means if we allocate a second bio, we're blocking the first one
from ever being freed.
Thus if enough threads call into a stacking block driver at the same
time with bios that need multiple splits, and the bio_set's reserve gets
used up, we deadlock.
This can be worked around in the driver code - we could check if we're
running under generic_make_request(), then mask out __GFP_WAIT when we
go to allocate a bio, and if the allocation fails punt to workqueue and
retry the allocation.
But this is tricky and not a generic solution. This patch solves it for
all users by inverting the previously described technique. We allocate a
rescuer workqueue for each bio_set, and then in the allocation code if
there are bios on current->bio_list we would be blocking, we punt them
to the rescuer workqueue to be submitted.
This guarantees forward progress for bio allocations under
generic_make_request() provided each bio is submitted before allocating
the next, and provided the bios are freed after they complete.
Note that this doesn't do anything for allocation from other mempools.
Instead of allocating per bio data structures from a mempool, code
should use bio_set's front_pad.
Tested it by forcing the rescue codepath to be taken (by disabling the
first GFP_NOWAIT) attempt, and then ran it with bcache (which does a lot
of arbitrary bio splitting) and verified that the rescuer was being
invoked.
Signed-off-by: Kent Overstreet <koverstreet@google.com>
CC: Jens Axboe <axboe@kernel.dk>
Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Muthukumar Ratty <muthur@gmail.com>
2012-09-10 14:33:46 -07:00
|
|
|
|
2009-02-21 11:16:36 +01:00
|
|
|
|
|
|
|
|
|
2012-05-25 13:03:11 -07:00
|
|
|
|
2022-01-24 10:11:06 +01:00
|
|
|
|
2022-01-24 10:11:03 +01:00
|
|
|
|
2022-01-24 10:11:06 +01:00
|
|
|
|
2021-01-26 15:52:34 +01:00
|
|
|
|
2022-01-24 10:11:06 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-09-06 15:35:01 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-02-21 11:16:36 +01:00
|
|
|
|
|
|
|
|
|
2018-05-08 21:33:50 -04:00
|
|
|
|
2009-02-21 11:16:36 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-09-26 16:19:21 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-01-26 15:52:34 +01:00
|
|
|
|
2022-04-06 08:12:27 +02:00
|
|
|
|
|
|
|
|
|
2021-01-26 15:52:34 +01:00
|
|
|
|
|
|
|
|
|
2022-04-06 08:12:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-06 04:44:50 -04:00
|
|
|
|
2022-04-06 08:12:27 +02:00
|
|
|
|
2021-01-26 15:52:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-06 08:12:27 +02:00
|
|
|
|
2021-01-26 15:52:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-06 08:12:27 +02:00
|
|
|
|
2021-01-26 15:52:34 +01:00
|
|
|
|
2022-04-06 08:12:27 +02:00
|
|
|
|
2021-01-26 15:52:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-12 15:46:57 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-11-23 17:19:00 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-07-27 07:56:36 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-04-12 15:46:57 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2020-01-05 09:41:14 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-12 18:18:04 +02:00
|
|
|
|
2019-12-28 07:05:48 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-05 09:41:14 +08:00
|
|
|
|
2019-12-28 07:05:48 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-01-09 18:36:43 +09:00
|
|
|
|
|
|
|
|
|
2019-12-28 07:05:48 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-25 16:48:40 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-24 11:02:34 +01:00
|
|
|
|
2020-03-25 16:48:40 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-08 11:37:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-12-01 16:19:18 -07:00
|
|
|
|
|
|
|
|
|
2021-03-08 11:37:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-29 07:13:09 -06:00
|
|
|
|
2021-03-08 11:37:47 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-18 14:38:59 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-08 11:37:47 -07:00
|
|
|
|
2021-10-12 18:17:57 +02:00
|
|
|
|
2021-03-08 11:37:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-17 16:23:59 -06:00
|
|
|
|
2022-10-18 20:50:55 +01:00
|
|
|
|
2021-03-08 11:37:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-12-01 16:19:18 -07:00
|
|
|
|
2023-02-24 09:59:44 -07:00
|
|
|
|
2021-12-01 16:19:18 -07:00
|
|
|
|
2021-03-08 11:37:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-17 16:23:59 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-09-26 16:19:21 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2022-02-02 17:01:08 +01:00
|
|
|
|
2013-11-23 18:19:27 -08:00
|
|
|
|
2015-07-24 12:37:59 -06:00
|
|
|
|
2018-11-12 10:35:25 -07:00
|
|
|
|
2013-11-23 18:19:27 -08:00
|
|
|
|
2016-07-27 07:22:05 +02:00
|
|
|
|
2022-05-04 07:29:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-02 17:01:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-23 18:19:27 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-02 17:01:09 +01:00
|
|
|
|
|
|
|
|
|
2022-02-02 17:01:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-23 18:19:27 -08:00
|
|
|
|
2022-02-02 17:01:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-23 18:19:27 -08:00
|
|
|
|
2022-02-02 17:01:09 +01:00
|
|
|
|
|
|
|
|
|
2013-11-23 18:19:27 -08:00
|
|
|
|
2022-02-02 17:01:08 +01:00
|
|
|
|
2013-11-23 18:19:27 -08:00
|
|
|
|
2022-02-02 17:01:09 +01:00
|
|
|
|
2022-02-02 17:01:08 +01:00
|
|
|
|
2013-11-23 18:19:27 -08:00
|
|
|
|
|
|
|
|
|
2022-02-02 17:01:08 +01:00
|
|
|
|
|
|
|
|
|
2022-02-02 17:01:06 +01:00
|
|
|
|
|
|
|
|
|
2022-02-02 17:01:08 +01:00
|
|
|
|
2013-11-23 18:19:27 -08:00
|
|
|
|
2022-02-02 17:01:08 +01:00
|
|
|
|
2013-11-23 18:19:27 -08:00
|
|
|
|
2022-02-02 17:01:09 +01:00
|
|
|
|
2013-11-23 18:19:27 -08:00
|
|
|
|
2022-02-02 17:01:08 +01:00
|
|
|
|
2022-02-02 17:01:09 +01:00
|
|
|
|
|
|
|
|
|
2022-02-02 17:01:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-02 17:01:09 +01:00
|
|
|
|
|
|
|
|
|
2022-02-02 17:01:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-02 17:01:09 +01:00
|
|
|
|
2022-02-02 17:01:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-02 17:01:09 +01:00
|
|
|
|
2022-02-02 17:01:08 +01:00
|
|
|
|
2021-10-12 18:18:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-17 18:01:07 +08:00
|
|
|
|
|
|
|
|
|
2019-06-17 11:14:11 +02:00
|
|
|
|
2019-03-17 18:01:07 +08:00
|
|
|
|
2020-08-17 20:52:06 +01:00
|
|
|
|
|
|
|
|
|
2019-03-17 18:01:07 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-11 08:23:31 +02:00
|
|
|
|
2019-06-17 11:14:11 +02:00
|
|
|
|
2020-08-17 20:52:06 +01:00
|
|
|
|
|
|
|
|
|
2022-09-15 17:04:02 +02:00
|
|
|
|
|
|
|
|
|
2020-08-17 20:52:06 +01:00
|
|
|
|
2019-03-17 18:01:07 +08:00
|
|
|
|
|
|
|
|
|
2021-10-12 18:18:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-12 17:55:46 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-29 15:08:00 +08:00
|
|
|
|
2019-08-12 17:39:57 +02:00
|
|
|
|
2019-03-29 15:08:00 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-08-12 17:39:57 +02:00
|
|
|
|
2019-03-29 15:08:00 +08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2020-05-12 17:55:46 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-23 22:30:22 -08:00
|
|
|
|
2020-05-12 17:55:46 +09:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2020-05-12 17:55:46 +09:00
|
|
|
|
2019-03-17 18:01:08 +08:00
|
|
|
|
2020-05-12 17:55:46 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-12 17:55:46 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2020-05-12 17:55:46 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-01-06 09:43:28 +01:00
|
|
|
|
2020-05-12 17:55:46 +09:00
|
|
|
|
2019-08-12 17:39:57 +02:00
|
|
|
|
2019-08-12 17:39:56 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-08-12 17:39:57 +02:00
|
|
|
|
2022-07-27 12:23:00 -04:00
|
|
|
|
2019-08-12 17:39:56 +02:00
|
|
|
|
2006-01-06 09:43:28 +01:00
|
|
|
|
|
|
|
|
|
2019-07-01 15:14:46 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2019-06-06 12:29:01 +02:00
|
|
|
|
2019-03-29 15:08:00 +08:00
|
|
|
|
|
|
|
|
|
2014-12-10 14:16:53 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-25 09:04:35 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2019-03-17 18:01:08 +08:00
|
|
|
|
2020-05-12 17:55:46 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-17 18:01:08 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-08-12 17:39:58 +02:00
|
|
|
|
2020-05-12 17:55:46 +09:00
|
|
|
|
|
|
|
|
|
2019-03-17 18:01:08 +08:00
|
|
|
|
2009-09-26 16:19:21 +02:00
|
|
|
|
2005-11-11 05:30:27 -06:00
|
|
|
|
2021-02-04 19:21:40 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-14 15:03:28 +01:00
|
|
|
|
2021-02-04 19:21:40 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-06 09:03:37 +02:00
|
|
|
|
2021-02-04 19:21:40 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-01 09:03:05 -07:00
|
|
|
|
2019-04-23 10:51:04 +08:00
|
|
|
|
2018-06-01 09:03:05 -07:00
|
|
|
|
2019-04-23 10:51:04 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-01 09:03:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-23 22:30:22 -08:00
|
|
|
|
2018-06-01 09:03:05 -07:00
|
|
|
|
2019-07-01 15:14:46 +08:00
|
|
|
|
2018-06-01 09:03:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-23 22:30:22 -08:00
|
|
|
|
|
|
|
|
|
2018-06-01 09:03:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-23 10:51:04 +08:00
|
|
|
|
2018-06-01 09:03:05 -07:00
|
|
|
|
2019-04-23 10:51:04 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-06-01 09:03:05 -07:00
|
|
|
|
2019-04-23 10:51:04 +08:00
|
|
|
|
2018-06-01 09:03:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-17 11:14:11 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-07-01 15:14:46 +08:00
|
|
|
|
2018-06-01 09:03:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-23 22:30:22 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-09-26 16:19:21 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-04-08 01:33:45 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-01-28 12:34:54 +08:00
|
|
|
|
2021-04-08 01:33:45 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-19 22:24:14 +01:00
|
|
|
|
2019-04-11 08:23:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-26 15:49:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-11 08:23:30 +02:00
|
|
|
|
2019-06-26 15:49:21 +02:00
|
|
|
|
2019-04-11 08:23:30 +02:00
|
|
|
|
2021-10-19 22:24:14 +01:00
|
|
|
|
2019-04-11 08:23:30 +02:00
|
|
|
|
2021-10-27 13:21:07 +01:00
|
|
|
|
2018-11-30 08:47:03 -07:00
|
|
|
|
2021-10-23 17:21:33 +01:00
|
|
|
|
|
|
|
|
|
2021-02-02 18:19:29 +01:00
|
|
|
|
2021-01-09 16:03:03 +00:00
|
|
|
|
2021-10-23 17:21:33 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-09 16:03:03 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-23 17:21:33 +01:00
|
|
|
|
2021-02-02 18:19:26 +01:00
|
|
|
|
2021-02-02 18:19:27 +01:00
|
|
|
|
2021-03-25 00:47:26 +09:00
|
|
|
|
2021-01-09 16:03:03 +00:00
|
|
|
|
2022-06-10 12:58:21 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-20 08:28:21 +02:00
|
|
|
|
|
|
|
|
|
2016-10-31 11:59:24 -06:00
|
|
|
|
2018-07-25 23:15:09 +02:00
|
|
|
|
2016-10-31 11:59:24 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-07-25 23:15:09 +02:00
|
|
|
|
2016-10-31 11:59:24 -06:00
|
|
|
|
2018-07-25 23:15:09 +02:00
|
|
|
|
2020-07-30 18:42:28 -07:00
|
|
|
|
2016-10-31 11:59:24 -06:00
|
|
|
|
2018-07-25 23:15:09 +02:00
|
|
|
|
2016-10-31 11:59:24 -06:00
|
|
|
|
2018-09-20 08:28:21 +02:00
|
|
|
|
|
|
|
|
|
2016-10-31 11:59:24 -06:00
|
|
|
|
|
|
|
|
|
2018-09-20 08:28:21 +02:00
|
|
|
|
2022-07-12 08:32:56 -07:00
|
|
|
|
2022-06-09 10:37:57 -04:00
|
|
|
|
2022-07-12 08:32:54 -07:00
|
|
|
|
2018-09-20 08:28:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-10 12:58:21 -07:00
|
|
|
|
2018-09-20 08:28:21 +02:00
|
|
|
|
|
|
|
|
|
2016-10-31 11:59:24 -06:00
|
|
|
|
2022-06-10 12:58:29 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-09 10:37:57 -04:00
|
|
|
|
2022-07-12 08:32:55 -07:00
|
|
|
|
2022-06-09 10:37:57 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-12 08:32:56 -07:00
|
|
|
|
|
|
|
|
|
2016-10-31 11:59:24 -06:00
|
|
|
|
2018-09-20 08:28:21 +02:00
|
|
|
|
|
|
|
|
|
2016-10-31 11:59:24 -06:00
|
|
|
|
2018-09-20 08:28:21 +02:00
|
|
|
|
2022-07-12 08:32:55 -07:00
|
|
|
|
2022-06-10 12:58:21 -07:00
|
|
|
|
|
|
|
|
|
2022-07-12 08:32:56 -07:00
|
|
|
|
2022-07-12 08:32:55 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-17 11:14:12 +02:00
|
|
|
|
2018-09-20 08:28:21 +02:00
|
|
|
|
2016-10-31 11:59:24 -06:00
|
|
|
|
|
|
|
|
|
2022-06-09 10:37:57 -04:00
|
|
|
|
2022-07-12 08:32:56 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-12 08:32:54 -07:00
|
|
|
|
2016-10-31 11:59:24 -06:00
|
|
|
|
2018-07-25 23:15:09 +02:00
|
|
|
|
|
|
|
|
|
2018-11-30 08:47:03 -07:00
|
|
|
|
2018-07-25 23:15:09 +02:00
|
|
|
|
2018-11-30 08:47:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-09 16:03:03 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-07-25 23:15:09 +02:00
|
|
|
|
|
|
|
|
|
2020-09-09 11:44:33 +02:00
|
|
|
|
2018-11-30 08:47:03 -07:00
|
|
|
|
|
|
|
|
|
2018-07-25 23:15:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-09 16:03:03 +00:00
|
|
|
|
2019-04-11 08:23:29 +02:00
|
|
|
|
2021-01-09 16:03:03 +00:00
|
|
|
|
2021-10-23 17:21:33 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-09 16:03:03 +00:00
|
|
|
|
2018-07-25 23:15:09 +02:00
|
|
|
|
|
|
|
|
|
2022-06-10 12:58:21 -07:00
|
|
|
|
2019-07-01 15:14:46 +08:00
|
|
|
|
2018-07-25 23:15:09 +02:00
|
|
|
|
2019-04-11 08:23:29 +02:00
|
|
|
|
2018-07-25 23:15:09 +02:00
|
|
|
|
2020-05-12 17:55:53 +09:00
|
|
|
|
2016-10-31 11:59:24 -06:00
|
|
|
|
2015-07-20 15:29:37 +02:00
|
|
|
|
2012-09-10 14:41:12 -07:00
|
|
|
|
2017-10-25 17:55:57 +09:00
|
|
|
|
2012-09-10 14:41:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-02 10:25:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-10 14:41:12 -07:00
|
|
|
|
2016-06-05 14:31:41 -05:00
|
|
|
|
2012-09-10 14:41:12 -07:00
|
|
|
|
2021-01-24 11:02:34 +01:00
|
|
|
|
|
|
|
|
|
2020-03-18 11:43:36 +08:00
|
|
|
|
2012-09-10 14:41:12 -07:00
|
|
|
|
2017-10-25 17:55:57 +09:00
|
|
|
|
2012-09-10 14:41:12 -07:00
|
|
|
|
2016-08-05 15:35:16 -06:00
|
|
|
|
2016-06-05 14:31:41 -05:00
|
|
|
|
2020-03-18 11:43:36 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-10 14:41:12 -07:00
|
|
|
|
2017-10-25 17:55:57 +09:00
|
|
|
|
2012-09-10 14:41:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-13 09:01:43 -06:00
|
|
|
|
2012-09-28 13:17:55 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
block: Inline encryption support for blk-mq
We must have some way of letting a storage device driver know what
encryption context it should use for en/decrypting a request. However,
it's the upper layers (like the filesystem/fscrypt) that know about and
manages encryption contexts. As such, when the upper layer submits a bio
to the block layer, and this bio eventually reaches a device driver with
support for inline encryption, the device driver will need to have been
told the encryption context for that bio.
We want to communicate the encryption context from the upper layer to the
storage device along with the bio, when the bio is submitted to the block
layer. To do this, we add a struct bio_crypt_ctx to struct bio, which can
represent an encryption context (note that we can't use the bi_private
field in struct bio to do this because that field does not function to pass
information across layers in the storage stack). We also introduce various
functions to manipulate the bio_crypt_ctx and make the bio/request merging
logic aware of the bio_crypt_ctx.
We also make changes to blk-mq to make it handle bios with encryption
contexts. blk-mq can merge many bios into the same request. These bios need
to have contiguous data unit numbers (the necessary changes to blk-merge
are also made to ensure this) - as such, it suffices to keep the data unit
number of just the first bio, since that's all a storage driver needs to
infer the data unit number to use for each data block in each bio in a
request. blk-mq keeps track of the encryption context to be used for all
the bios in a request with the request's rq_crypt_ctx. When the first bio
is added to an empty request, blk-mq will program the encryption context
of that bio into the request_queue's keyslot manager, and store the
returned keyslot in the request's rq_crypt_ctx. All the functions to
operate on encryption contexts are in blk-crypto.c.
Upper layers only need to call bio_crypt_set_ctx with the encryption key,
algorithm and data_unit_num; they don't have to worry about getting a
keyslot for each encryption context, as blk-mq/blk-crypto handles that.
Blk-crypto also makes it possible for request-based layered devices like
dm-rq to make use of inline encryption hardware by cloning the
rq_crypt_ctx and programming a keyslot in the new request_queue when
necessary.
Note that any user of the block layer can submit bios with an
encryption context, such as filesystems, device-mapper targets, etc.
Signed-off-by: Satya Tangirala <satyat@google.com>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-05-14 00:37:18 +00:00
|
|
|
|
2013-08-07 14:26:21 -07:00
|
|
|
|
2012-09-28 13:17:55 -07:00
|
|
|
|
2021-10-13 09:01:43 -06:00
|
|
|
|
2012-09-28 13:17:55 -07:00
|
|
|
|
2018-05-08 21:33:54 -04:00
|
|
|
|
|
|
|
|
|
2012-09-10 13:57:51 -07:00
|
|
|
|
2018-05-08 21:33:54 -04:00
|
|
|
|
2021-07-27 07:56:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-24 16:39:19 +02:00
|
|
|
|
|
|
|
|
|
2021-07-27 07:56:41 +02:00
|
|
|
|
2022-05-24 16:39:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-27 07:56:41 +02:00
|
|
|
|
2018-05-08 21:33:55 -04:00
|
|
|
|
2020-11-24 17:58:13 +00:00
|
|
|
|
|
|
|
|
|
2012-09-10 13:57:51 -07:00
|
|
|
|
|
|
|
|
|
2018-05-08 21:33:53 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-05-08 21:33:54 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-05-08 21:33:53 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-05-08 21:33:54 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-05-08 21:33:53 -04:00
|
|
|
|
2012-09-10 13:57:51 -07:00
|
|
|
|
|
|
|
|
|
2016-09-22 03:10:01 -04:00
|
|
|
|
2015-01-18 16:16:30 +01:00
|
|
|
|
|
|
|
|
|
2019-02-15 19:13:19 +08:00
|
|
|
|
2015-01-18 16:16:30 +01:00
|
|
|
|
2019-04-25 09:03:00 +02:00
|
|
|
|
2015-01-18 16:16:30 +01:00
|
|
|
|
|
|
|
|
|
2016-09-22 03:10:01 -04:00
|
|
|
|
2015-01-18 16:16:30 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-25 18:12:08 +03:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-05 15:22:02 -07:00
|
|
|
|
2019-02-15 19:13:19 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2019-04-25 09:03:00 +02:00
|
|
|
|
2018-07-24 14:04:13 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-07-24 14:04:12 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-04-01 15:29:48 +03:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-11-22 14:55:48 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-11-22 14:55:48 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-11-22 14:55:48 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2018-07-24 14:04:12 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2018-07-24 14:04:12 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2018-07-24 14:04:12 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2018-07-24 14:04:12 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2019-06-26 15:49:21 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-05 15:22:02 -07:00
|
|
|
|
2018-07-24 14:04:12 +02:00
|
|
|
|
2019-02-15 19:13:19 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2019-04-25 09:03:00 +02:00
|
|
|
|
2018-07-24 14:04:12 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2019-06-26 15:49:21 +02:00
|
|
|
|
2018-07-24 14:04:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2015-04-17 16:15:18 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-22 09:14:03 -04:00
|
|
|
|
2015-07-24 12:37:59 -06:00
|
|
|
|
2015-04-17 16:15:18 -06:00
|
|
|
|
2015-05-22 09:14:03 -04:00
|
|
|
|
2015-04-17 16:15:18 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-20 15:29:37 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-24 20:30:30 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-07-20 15:29:37 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-03-11 17:34:52 +01:00
|
|
|
|
2016-03-11 17:34:53 +01:00
|
|
|
|
2016-03-11 17:34:52 +01:00
|
|
|
|
2017-07-03 16:58:43 -06:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2022-03-13 21:15:02 -10:00
|
|
|
|
2018-07-03 11:15:00 -04:00
|
|
|
|
2021-06-24 20:30:30 +08:00
|
|
|
|
2021-10-14 15:03:28 +01:00
|
|
|
|
2021-06-24 20:30:30 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-03-11 17:34:52 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-23 18:34:15 -08:00
|
|
|
|
2016-03-11 17:34:52 +01:00
|
|
|
|
blk-throttle: add a simple idle detection
A cgroup gets assigned a low limit, but the cgroup could never dispatch
enough IO to cross the low limit. In such case, the queue state machine
will remain in LIMIT_LOW state and all other cgroups will be throttled
according to low limit. This is unfair for other cgroups. We should
treat the cgroup idle and upgrade the state machine to lower state.
We also have a downgrade logic. If the state machine upgrades because of
cgroup idle (real idle), the state machine will downgrade soon as the
cgroup is below its low limit. This isn't what we want. A more
complicated case is cgroup isn't idle when queue is in LIMIT_LOW. But
when queue gets upgraded to lower state, other cgroups could dispatch
more IO and this cgroup can't dispatch enough IO, so the cgroup is below
its low limit and looks like idle (fake idle). In this case, the queue
should downgrade soon. The key to determine if we should do downgrade is
to detect if cgroup is truely idle.
Unfortunately it's very hard to determine if a cgroup is real idle. This
patch uses the 'think time check' idea from CFQ for the purpose. Please
note, the idea doesn't work for all workloads. For example, a workload
with io depth 8 has disk utilization 100%, hence think time is 0, eg,
not idle. But the workload can run higher bandwidth with io depth 16.
Compared to io depth 16, the io depth 8 workload is idle. We use the
idea to roughly determine if a cgroup is idle.
We treat a cgroup idle if its think time is above a threshold (by
default 1ms for SSD and 100ms for HD). The idea is think time above the
threshold will start to harm performance. HD is much slower so a longer
think time is ok.
The patch (and the latter patches) uses 'unsigned long' to track time.
We convert 'ns' to 'us' with 'ns >> 10'. This is fast but loses
precision, should not a big deal.
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-03-27 10:51:41 -07:00
|
|
|
|
2017-07-10 11:40:17 -07:00
|
|
|
|
|
|
|
|
|
2016-03-11 17:34:52 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-09-26 16:19:21 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-11-23 18:21:01 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-22 07:57:12 -04:00
|
|
|
|
2019-08-01 15:50:41 -07:00
|
|
|
|
|
|
|
|
|
2013-11-23 18:21:01 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-22 13:18:05 -05:00
|
|
|
|
2013-11-23 18:21:01 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-12 17:55:47 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-02 17:01:09 +01:00
|
|
|
|
2013-11-23 18:21:01 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-29 11:31:10 -07:00
|
|
|
|
2013-11-23 18:21:01 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
2018-01-23 09:10:19 -07:00
|
|
|
|
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
|
|
|
|
2013-11-23 18:21:01 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-07 11:14:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-21 21:43:32 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-07 11:14:32 -07:00
|
|
|
|
2021-07-21 21:43:32 +09:00
|
|
|
|
2013-08-07 11:14:32 -07:00
|
|
|
|
2021-07-21 21:43:32 +09:00
|
|
|
|
2022-04-14 16:44:43 +08:00
|
|
|
|
2021-07-21 21:43:32 +09:00
|
|
|
|
2013-08-07 11:14:32 -07:00
|
|
|
|
|
|
|
|
|
2013-10-11 15:44:27 -07:00
|
|
|
|
2013-08-07 11:14:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-10-11 15:44:27 -07:00
|
|
|
|
2017-06-29 11:31:08 -07:00
|
|
|
|
|
|
|
|
|
2017-06-29 11:31:10 -07:00
|
|
|
|
2013-08-07 11:14:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-05-08 21:33:50 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-02-02 18:19:29 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2018-05-08 21:33:50 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2018-05-08 21:33:51 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-03-08 11:37:47 -07:00
|
|
|
|
block: Avoid deadlocks with bio allocation by stacking drivers
Previously, if we ever try to allocate more than once from the same bio
set while running under generic_make_request() (i.e. a stacking block
driver), we risk deadlock.
This is because of the code in generic_make_request() that converts
recursion to iteration; any bios we submit won't actually be submitted
(so they can complete and eventually be freed) until after we return -
this means if we allocate a second bio, we're blocking the first one
from ever being freed.
Thus if enough threads call into a stacking block driver at the same
time with bios that need multiple splits, and the bio_set's reserve gets
used up, we deadlock.
This can be worked around in the driver code - we could check if we're
running under generic_make_request(), then mask out __GFP_WAIT when we
go to allocate a bio, and if the allocation fails punt to workqueue and
retry the allocation.
But this is tricky and not a generic solution. This patch solves it for
all users by inverting the previously described technique. We allocate a
rescuer workqueue for each bio_set, and then in the allocation code if
there are bios on current->bio_list we would be blocking, we punt them
to the rescuer workqueue to be submitted.
This guarantees forward progress for bio allocations under
generic_make_request() provided each bio is submitted before allocating
the next, and provided the bios are freed after they complete.
Note that this doesn't do anything for allocation from other mempools.
Instead of allocating per bio data structures from a mempool, code
should use bio_set's front_pad.
Tested it by forcing the rescue codepath to be taken (by disabling the
first GFP_NOWAIT) attempt, and then ran it with bcache (which does a lot
of arbitrary bio splitting) and verified that the rescuer was being
invoked.
Signed-off-by: Kent Overstreet <koverstreet@google.com>
CC: Jens Axboe <axboe@kernel.dk>
Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Muthukumar Ratty <muthur@gmail.com>
2012-09-10 14:33:46 -07:00
|
|
|
|
|
|
|
|
|
2018-05-08 21:33:51 -04:00
|
|
|
|
block: Avoid deadlocks with bio allocation by stacking drivers
Previously, if we ever try to allocate more than once from the same bio
set while running under generic_make_request() (i.e. a stacking block
driver), we risk deadlock.
This is because of the code in generic_make_request() that converts
recursion to iteration; any bios we submit won't actually be submitted
(so they can complete and eventually be freed) until after we return -
this means if we allocate a second bio, we're blocking the first one
from ever being freed.
Thus if enough threads call into a stacking block driver at the same
time with bios that need multiple splits, and the bio_set's reserve gets
used up, we deadlock.
This can be worked around in the driver code - we could check if we're
running under generic_make_request(), then mask out __GFP_WAIT when we
go to allocate a bio, and if the allocation fails punt to workqueue and
retry the allocation.
But this is tricky and not a generic solution. This patch solves it for
all users by inverting the previously described technique. We allocate a
rescuer workqueue for each bio_set, and then in the allocation code if
there are bios on current->bio_list we would be blocking, we punt them
to the rescuer workqueue to be submitted.
This guarantees forward progress for bio allocations under
generic_make_request() provided each bio is submitted before allocating
the next, and provided the bios are freed after they complete.
Note that this doesn't do anything for allocation from other mempools.
Instead of allocating per bio data structures from a mempool, code
should use bio_set's front_pad.
Tested it by forcing the rescue codepath to be taken (by disabling the
first GFP_NOWAIT) attempt, and then ran it with bcache (which does a lot
of arbitrary bio splitting) and verified that the rescuer was being
invoked.
Signed-off-by: Kent Overstreet <koverstreet@google.com>
CC: Jens Axboe <axboe@kernel.dk>
Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Muthukumar Ratty <muthur@gmail.com>
2012-09-10 14:33:46 -07:00
|
|
|
|
2018-05-08 21:33:50 -04:00
|
|
|
|
|
|
|
|
|
2012-10-12 15:29:33 -07:00
|
|
|
|
2009-06-26 15:37:49 +02:00
|
|
|
|
2018-05-08 21:33:51 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2018-05-08 21:33:51 -04:00
|
|
|
|
|
|
|
|
|
2018-05-20 18:25:58 -04:00
|
|
|
|
2018-05-08 21:33:51 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-05-20 18:25:58 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-02 17:01:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-05-20 18:25:58 -04:00
|
|
|
|
2018-05-08 21:33:51 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-11 11:05:54 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-05-08 21:33:51 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-11 11:05:52 +08:00
|
|
|
|
2018-05-08 21:33:51 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-08 11:37:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-05-08 21:33:51 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-02-02 18:19:23 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-26 15:37:49 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-02-02 18:19:23 +01:00
|
|
|
|
|
|
|
|
|
2008-12-05 16:10:29 +01:00
|
|
|
|
2021-02-02 18:19:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2021-03-08 11:37:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-02 10:40:11 -06:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2018-05-08 21:33:52 -04:00
|
|
|
|
2011-03-17 11:11:05 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
