- 18 Nov, 2018 1 commit
-
-
Jens Axboe authored
With the locking removed, it's unused. Kill it. Fixes: 503f620f ("floppy: remove queue_lock around floppy_end_request") Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
- 17 Nov, 2018 1 commit
-
-
Christoph Hellwig authored
Replace the lock in mmc_blk_data that is only used through a pointer in struct mmc_queue and to protect fields in that structure with an actual lock in struct mmc_queue. Suggested-by:
Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
- 16 Nov, 2018 12 commits
-
-
Christoph Hellwig authored
blk_mq_stop_hw_queues doesn't need any locking, and the ide dev_flags field isn't protected by it either. Reviewed-by:
Omar Sandoval <osandov@fb.com> Signed-off-by:
-
Christoph Hellwig authored
There is nothing we can synchronize against over a call to blk_queue_dying. Reviewed-by:
-
Christoph Hellwig authored
blk_queue_max_hw_sectors can't do anything with queue_lock protection so don't hold it. Reviewed-by:
-
Christoph Hellwig authored
There is nothing the queue_lock could protect inside floppy_end_request, so remove it. Reviewed-by:
-
Christoph Hellwig authored
Reviewed-by:
-
Jens Axboe authored
Those will go straight to issue inside blk-mq, so don't bother setting up a block plug for them. Reviewed-by:
-
Jens Axboe authored
Inherit the iocb IOCB_HIPRI flag, and pass on REQ_HIPRI for those kinds of requests. Reviewed-by:
-
Jens Axboe authored
If we're polling for IO on a device that doesn't use interrupts, then IO completion loop (and wake of task) is done by submitting task itself. If that is the case, then we don't need to enter the wake_up_process() function, we can simply mark ourselves as TASK_RUNNING. Reviewed-by:
-
Jens Axboe authored
Put the short code in the fast path, where we don't have any functions attached to the queue. This minimizes the impact on the hot path in the core code. Cc: Josef Bacik <josef@toxicpanda.com> Reviewed-by:
-
Jens Axboe authored
Various spots check for q->mq_ops being non-NULL, but provide a helper to do this instead. Where the ->mq_ops != NULL check is redundant, remove it. Since mq == rq-based now that legacy is gone, get rid of the queue_is_rq_based() and just use queue_is_mq() everywhere. Reviewed-by:
-
Jens Axboe authored
If we have separate poll queues, we know that they aren't using interrupts. Hence we don't need to disable interrupts around finding completions. Provide a separate set of blk_mq_ops for such devices. Signed-off-by: -
Jens Axboe authored
The initial patch cleared this for all requests, which is wrong since internal uses can't have this cleared as that's what they are using to pass data. The fix moved the initialization to the mq_ops->initialize_rq_fn(), but that's only a partial fix since it only catches uses from blk_get_request(), not requests coming from the file system. Keep the non-fs initialization, and add the IDE entry clear IFF RQF_DONTPREP isn't set and it's a passthrough request. Fixes: d16a6766 ("ide: don't clear special on ide_queue_rq() entry") Fixes: 22ce0a7c ("ide: don't use req->special") Reported-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
- 15 Nov, 2018 19 commits
-
-
Jens Axboe authored
At least on SPARC, if MSI/MSI-X isn't supported, we get EINVAL if we ask for more than one vector. This isn't covered by our ENOSPC check. If we get EINVAL, decrease our ask to just one vector, instead of bailing out in error. Fixes: 3b6592f7 ("nvme: utilize two queue maps, one for reads and one for writes") Reported-by:
-
Jens Axboe authored
This isn't unused, if BFQ is modular we get into trouble. Fixes: b6676f65 ("block: remove a few unused exports") Signed-off-by:
-
Christoph Hellwig authored
With the legacy request path gone there is no good reason to keep queue_lock as a pointer, we can always use the embedded lock now. Reviewed-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
-
Christoph Hellwig authored
With the legacy request path gone there is no real need to override the queue_lock. Reviewed-by:
-
Christoph Hellwig authored
mmc uses the block layer struct request pointer to indirect their own lock to the mmc_queue structure, given that the original lock isn't reachable outside of block.c. Add a lock pointer to struct mmc_queue instead and stop overriding the block layer lock which protects fields entirely separate from the mmc use. Reviewed-by:
-
Christoph Hellwig authored
Merge three functions initializing the queue into a single one, and drop an unused argument for it. Reviewed-by:
-
Christoph Hellwig authored
The umem card->lock and the block layer queue_lock are used for entirely different resources. Stop using card->lock as the block layer queue_lock. Reviewed-by:
-
Christoph Hellwig authored
The DRBD req_lock and block layer queue_lock are used for entirely different resources. Stop using the req_lock as the block layer queue_lock. Reviewed-by:
-
Christoph Hellwig authored
Reviewed-by:
-
Christoph Hellwig authored
Use a goto label to merge two identical pieces of error handling code. Reviewed-by:
-
Christoph Hellwig authored
Reviewed-by:
-
Christoph Hellwig authored
Only the mq locking is left in the flush state machine. Reviewed-by:
-
Christoph Hellwig authored
Unused now that the legacy request path is gone. Reviewed-by:
-
Christoph Hellwig authored
The only remaining user unconditionally drops and reacquires the lock, which means we really don't need any additional (conditional) annotation. Reviewed-by:
-
Christoph Hellwig authored
->queue_flags is generally not set or cleared in the fast path, and also generally set or cleared one flag at a time. Make use of the normal atomic bitops for it so that we don't need to take the queue_lock, which is otherwise mostly unused in the core block layer now. Reviewed-by:
-
Christoph Hellwig authored
There is nothing it could synchronize against, so don't go through the pains of acquiring the lock. Reviewed-by:
-
Christoph Hellwig authored
No users left since the removal of the legacy request interface, we can remove all the magic bit stealing now and make it a normal field. But use WRITE_ONCE/READ_ONCE on the new deadline field, given that we don't seem to have any mechanism to guarantee a new value actually gets seen by other threads. Reviewed-by:
-
Christoph Hellwig authored
Unused since the removal of the legacy request code. Reviewed-by:
-
Eric Biggers authored
blk_try_req_merge() is only used in block/blk-merge.c, so make it static. This addresses a gcc warning when -Wmissing-prototypes is enabled. Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
-
- 14 Nov, 2018 3 commits
-
-
Jens Axboe authored
No more users of ->in_flight[] or ->nr_sorted, get rid of them. Fixes: a1ce35fa ("block: remove dead elevator code") Signed-off-by:
-
Colin Ian King authored
The boolean next_sorted is set to false and is never changed, hence the code that checks if it is true is dead code and can now be removed. This dead code occurred from a previous commit that cleaned up the elevator and removed the setting of next_sorted to true. Detected by CoverityScan, CID#1475401 ("'Constant' variable guards dead code") Fixes: a1ce35fa ("block: remove dead elevator code") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Jens Axboe authored
NVMe always asks for io_queues + 1 worth of IRQ vectors, which means that even when we scale all the way down, we still ask for 2 vectors and get -ENOSPC in return if the system can't support more than 1. Getting just 1 vector is fine, it just means that we'll have 1 IO queue and 1 admin queue, with a shared vector between them. Check for this case and don't add our + 1 if it happens. Fixes: 3b6592f7 ("nvme: utilize two queue maps, one for reads and one for writes") Reported-by:
-
- 13 Nov, 2018 1 commit
-
-
Jens Axboe authored
We can't use RQF_DONTPREP to see if we should clear ->special, as someone could have set that while inserting the request. Make sure we clear it in our ->initialize_rq_fn() helper instead. Fixes: 22ce0a7c ("ide: don't use req->special") Signed-off-by:
-
- 12 Nov, 2018 1 commit
-
-
Tetsuo Handa authored
Commit 0a42e99b ("loop: Get rid of loop_index_mutex") forgot to remove mutex_unlock(&loop_ctl_mutex) from loop_control_ioctl() when replacing loop_index_mutex with loop_ctl_mutex. Fixes: 0a42e99b ("loop: Get rid of loop_index_mutex") Reported-by:
syzbot <syzbot+c0138741c2290fc5e63f@syzkaller.appspotmail.com> Reviewed-by:
Ming Lei <ming.lei@redhat.com> Reviewed-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by:
-
- 10 Nov, 2018 2 commits
-
-
Jens Axboe authored
The compiler rightfully complains: drivers/block/null_blk_main.c: In function ‘null_complete_rq’: drivers/block/null_blk_main.c:647:16: warning: unused variable ‘nullb’ [-Wunused-variable] struct nullb *nullb = rq->q->queuedata; ^~~~~ Fixes: 49f66136 ("nullb: remove leftover legacy request code") Signed-off-by: -
Christoph Hellwig authored
Just replace it with a field of the same name in struct ide_req. Reviewed-by:
-
