linux-stable.git/block/blk.h, branch v5.8

block: nr_sects_write(): Disable preemption on seqcount write

2020-06-05T03:22:28+00:00

For optimized block readers not holding a mutex, the "number of sectors"
64-bit value is protected from tearing on 32-bit architectures by a
sequence counter.

Disable preemption before entering that sequence counter's write side
critical section. Otherwise, the read side can preempt the write side
section and spin for the entire scheduler tick. If the reader belongs to
a real-time scheduling class, it can spin forever and the kernel will
livelock.

Fixes: c83f6bf98dc1 ("block: add partition resize function to blkpg ioctl")
Cc: 
Signed-off-by: Ahmed S. Darwish 
Reviewed-by: Sebastian Andrzej Siewior 
Signed-off-by: Jens Axboe

blk-throttle: remove blk_throtl_drain

2020-05-29T22:30:39+00:00

After the commit 5addeae1bedc4 ("blk-cgroup: remove blkcg_drain_queue"),
there is no caller of blk_throtl_drain, so let's remove it.

Signed-off-by: Guoqing Jiang 
Signed-off-by: Jens Axboe

block: add a blk_account_io_merge_bio helper

2020-05-27T11:21:23+00:00

Move the non-"new_io" branch of blk_account_io_start() into separate
function.  Fix merge accounting for discards (they were counted as write
merges).

The new blk_account_io_merge_bio() doesn't call update_io_ticks() unlike
blk_account_io_start(), as there is no reason for that.

[hch: rebased]

Signed-off-by: Konstantin Khlebnikov 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Jens Axboe

block: always use a percpu variable for disk stats

2020-05-27T11:21:23+00:00

percpu variables have a perfectly fine working stub implementation
for UP kernels, so use that.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Konstantin Khlebnikov 
Signed-off-by: Jens Axboe

block: move update_io_ticks to blk-core.c

2020-05-27T11:21:23+00:00

All callers are in blk-core.c, so move update_io_ticks over.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Konstantin Khlebnikov 
Signed-off-by: Jens Axboe

block: Remove unused flush_queue_delayed in struct blk_flush_queue

2020-05-19T15:42:46+00:00

The flush_queue_delayed was introdued to hold queue if flush is
running for non-queueable flush drive by commit 3ac0cc450870
("hold queue if flush is running for non-queueable flush drive"),
but the non mq parts of the flush code had been removed by
commit 7e992f847a08 ("block: remove non mq parts from the flush code"),
as well as removing the usage of the flush_queue_delayed flag.
Thus remove the unused flush_queue_delayed flag.

Signed-off-by: Baolin Wang 
Reviewed-by: Ming Lei 
Signed-off-by: Jens Axboe

block: merge part_{inc,dev}_in_flight into their only callers

2020-05-19T15:35:24+00:00

part_inc_in_flight and part_dec_in_flight only have one caller each, and
those callers are purely for bio based drivers.  Merge each function into
the only caller, and remove the superflous blk-mq checks.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Jens Axboe

block: mark blk_account_io_completion static

2020-05-19T15:35:24+00:00

Signed-off-by: Christoph Hellwig 
Signed-off-by: Jens Axboe

blk-mq: allow blk_mq_make_request to consume the q_usage_counter reference

2020-05-19T15:34:29+00:00

blk_mq_make_request currently needs to grab an q_usage_counter
reference when allocating a request.  This is because the block layer
grabs one before calling blk_mq_make_request, but also releases it as
soon as blk_mq_make_request returns.  Remove the blk_queue_exit call
after blk_mq_make_request returns, and instead let it consume the
reference.  This works perfectly fine for the block layer caller, just
device mapper needs an extra reference as the old problem still
persists there.  Open code blk_queue_enter_live in device mapper,
as there should be no other callers and this allows better documenting
why we do a non-try get.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Jens Axboe

block: Inline encryption support for blk-mq

2020-05-14T15:47:53+00:00

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 
Reviewed-by: Eric Biggers 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Jens Axboe