- 04 Apr, 2017 24 commits
-
-
James Smart authored
Update FC-NVME definitions to match FC-NVME r1.14 (16-020vB) plus change voted in by 2/22 FC-NVME Adhoc (see HOSTID below). Includes the following: - Addition of "status_code" field to ERSP IU - Addition of FC-NVME LS RJT reason_codes and reason_explanations - CreateAssociation payload, HostID field shortened to 16 bytes Signed-off-by:
James Smart <james.smart@broadcom.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
Jens Axboe <axboe@fb.com>
-
Sagi Grimberg authored
Before scheduling a reconnect attempt, check nr_reconnects against max_reconnects, if not exhausted (or max_reconnects is not -1), schedule a reconnect attempts, otherwise schedule ctrl removal. Reviewed-by:
-
Sagi Grimberg authored
When a host sense that its controller session is damaged, it tries to re-establish it periodically (reconnect every reconnect_delay). It may very well be that the controller is gone and never coming back, in this case the host will try to reconnect forever. Add a ctrl_loss_tmo to bound the number of reconnect attempts to a specific controller (default to a reasonable 10 minutes). The timeout configuration is actually translated into number of reconnect attempts and not a schedule on its own but rather divided with reconnect_delay. This is useful to prevent racing flows of remove and reconnect, and it doesn't really matter if we remove slightly sooner than what the user requested. Reviewed-by:
-
Sagi Grimberg authored
we already have it in opts. Reviewed-by:
-
Sagi Grimberg authored
useful to validate that the we didn't mess up the command_id. Signed-off-by:
-
Sagi Grimberg authored
Reviewed-by:
-
Sagi Grimberg authored
If nvmf_register_transport happened to fail (it can't, but theoretically) we leak memory. Signed-off-by:
-
Sagi Grimberg authored
if nvmf_register_transport happend to fail, we need to nvmet_unregister_transport as well. Signed-off-by:
-
Sagi Grimberg authored
If nvmf_register_transport happened to fail (it can't, but theoretically) we leak memory. Signed-off-by:
-
Max Gurtovoy authored
Signed-off-by:
Max Gurtovoy <maxg@mellanox.com> Reviewed-by:
Parav Pandit <parav@mellanox.com> Reviewed-by:
-
Parav Pandit authored
This patch introduces helper function for checking controller status during admin and io command processing which returns u16 status. As to bring consistency on returning status, other friend functions also now return u16 status instead of int to match the spec. As part of the theseerror log prints in also prints qid on which command error occured. Signed-off-by:
-
Parav Pandit authored
This patch avoids printing "nvmet:" twice in error logs as its already coming through pr_fmt macro. Reviewed-by:
-
Sagi Grimberg authored
Instead of parsing address strings, use a generic helper. Acked-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Sagi Grimberg authored
Both the destination and the host addresses are now parsed using inet_pton_with_scope helper. We also get ipv6 (with address scopes support). Reviewed-by:
-
Sagi Grimberg authored
Instead of parsing address strings, use a generic helper. This also adds ipv6 (with address scopes) support. Reviewed-by:
-
Sagi Grimberg authored
Several locations in the stack need to handle ipv4/ipv6 (with scope) and port strings conversion to sockaddr. Add a helper that takes either AF_INET, AF_INET6 or AF_UNSPEC (for wildcard) to centralize this handling. Suggested-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Sagi Grimberg authored
Signed-off-by:
-
Sagi Grimberg authored
The target might be occupied with multiple hosts so lets give it some more grace before failing the connection establishment. Signed-off-by:
-
Sagi Grimberg authored
If we are attacked with establishments/teradowns we need to make sure we do not consume too much system memory. Thus let ongoing controller teardowns complete before accepting new controller establishments. Signed-off-by:
-
Sagi Grimberg authored
If a cpu unplug event has occured, we need to take the minimum of the provided nr_io_queues and the number of online cpus, otherwise we won't be able to connect them as blk-mq mapping won't dispatch to those queues. Reviewed-by:
-
Sagi Grimberg authored
When handling a new recv command, we grab a new rsp resource and check for the queue state being live. In case the queue is not in live state, we simply restore the rsp back to the free list. However in this flow we didn't set rsp->queue yet, so we cannot dereference it. Instead, make sure to initialize rsp->queue (and other rsp members) as soon as possible so we won't reference uninitialized variables. Reported-by:
Yi Zhang <yizhan@redhat.com> Reported-by:
Raju Rangoju <rajur@chelsio.com> Reviewed-by:
-
Sagi Grimberg authored
percpu_ref_kill is not enough to prevent subsequent percpu_ref_tryget_live from failing. Hence call perfcpu_ref_kill_confirm to make it safe. Reviewed-by:
-
Sagi Grimberg authored
If a cpu unplug event has occured, we need to take the minimum of the provided nr_io_queues and the number of online cpus, otherwise we won't be able to connect them as blk-mq mapping won't dispatch to those queues. Reviewed-by:
-
Sagi Grimberg authored
we need to destroy the nvmet sq and let it finish gracefully before continue to cleanup the queue. Reviewed-by:
-
- 31 Mar, 2017 1 commit
-
-
Eric Biggers authored
Constify all instances of blk_mq_ops, as they are never modified. Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
-
- 30 Mar, 2017 4 commits
-
-
Jens Axboe authored
This adds a new module parameter to null_blk, blocking. If set, null_blk will set the BLK_MQ_F_BLOCKING flag, indicating that it sometimes/always needs to block in its ->queue_rq() function. The intent is to help find regressions in blocking drivers, since not many of them exist. If null_blk is loaded with submit_queues > 1 and blocking=1, this shows the regression recently fixed by bf4907c0. Reviewed-by:
Bart Van Assche <bart.vanassche@sandisk.com> Signed-off-by:
-
Jens Axboe authored
Commit a4d907b6 unified the single and multi queue request handlers, but in the process, it also screwed up the locking balance and calls blk_mq_try_issue_directly() with the ctx preempt lock held. This is a problem for drivers that have set BLK_MQ_F_BLOCKING, since now they can't reliably sleep. While in there, protect against similar issues in the future, by adding a might_sleep() trigger in the BLOCKING path for direct issue or queue run. Reported-by:
Josef Bacik <josef@toxicpanda.com> Tested-by:
-
Colin Ian King authored
trivial fix to spelling mistake in pr_err error message Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Minchan Kim authored
In blk_mq_alloc_request_hctx, blk_mq_sched_get_request doesn't get sw context so we don't need to put the context with blk_mq_put_ctx. Unless, we will see preempt counter underflow. Cc: Omar Sandoval <osandov@fb.com> Signed-off-by:
Minchan Kim <minchan@kernel.org> Reviewed-by:
-
- 29 Mar, 2017 11 commits
-
-
Jens Axboe authored
Currently we return true in blk_mq_dispatch_rq_list() if we queued IO successfully, but we really want to return whether or not the we made progress. Progress includes if we got an error return. If we don't, this can lead to a hang in blk_mq_sched_dispatch_requests() when a driver is draining IO by returning BLK_MQ_QUEUE_ERROR instead of manually ending the IO in error and return BLK_MQ_QUEUE_OK. Tested-by:
Omar Sandoval <osandov@fb.com> Signed-off-by:
-
Josef Bacik authored
When try to issue a request directly and we fail we will requeue the request, but call blk_mq_end_request() as well. This leads to the completed request being on a queuelist and getting ended twice, which causes list corruption in schedulers and other shenanigans. Signed-off-by:
Josef Bacik <jbacik@fb.com> Reviewed-by:
Ming Lei <tom.leiming@gmail.com> Reviewed-by:
-
Tahsin Erdogan authored
blkg_conf_prep() currently calls blkg_lookup_create() while holding request queue spinlock. This means allocating memory for struct blkcg_gq has to be made non-blocking. This causes occasional -ENOMEM failures in call paths like below: pcpu_alloc+0x68f/0x710 __alloc_percpu_gfp+0xd/0x10 __percpu_counter_init+0x55/0xc0 cfq_pd_alloc+0x3b2/0x4e0 blkg_alloc+0x187/0x230 blkg_create+0x489/0x670 blkg_lookup_create+0x9a/0x230 blkg_conf_prep+0x1fb/0x240 __cfqg_set_weight_device.isra.105+0x5c/0x180 cfq_set_weight_on_dfl+0x69/0xc0 cgroup_file_write+0x39/0x1c0 kernfs_fop_write+0x13f/0x1d0 __vfs_write+0x23/0x120 vfs_write+0xc2/0x1f0 SyS_write+0x44/0xb0 entry_SYSCALL_64_fastpath+0x18/0xad In the code path above, percpu allocator cannot call vmalloc() due to queue spinlock. A failure in this call path gives grief to tools which are trying to configure io weights. We see occasional failures happen shortly after reboots even when system is not under any memory pressure. Machines with a lot of cpus are more vulnerable to this condition. Do struct blkcg_gq allocations outside the queue spinlock to allow blocking during memory allocations. Suggested-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
Tahsin Erdogan <tahsin@google.com> Acked-by:
-
Jens Axboe authored
I inadvertently applied the v5 version of this patch, whereas the agreed upon version was v5. Revert this one so we can apply the right one. This reverts commit 7fc6b87a.
-
Jens Axboe authored
Signed-off-by: -
Sagi Grimberg authored
Signed-off-by:
-
Omar Sandoval authored
CONFIG_DEBUG_TEST_DRIVER_REMOVE found a possible leak of q->rq_wb when a request queue is reregistered. This has been a problem since wbt was introduced, but the WARN_ON(!list_empty(&stats->callbacks)) in the blk-stat rework exposed it. Fix it by cleaning up wbt when we unregister the queue. Fixes: 87760e5e ("block: hook up writeback throttling") Signed-off-by:
-
Omar Sandoval authored
blk_alloc_queue_node() already allocates q->stats, so blk_mq_init_allocated_queue() is overwriting it with a new allocation. Fixes: a83b576c ("block: fix stacked driver stats init and free") Reviewed-by:
-
Omar Sandoval authored
Now that the remaining drivers have been converted to one request queue per gendisk, let's warn if a request queue gets registered more than once. This will catch future drivers which might do it inadvertently or any old drivers that I may have missed. Signed-off-by:
-
Ming Lei authored
Before commit 780db207(blk-mq: decouble blk-mq freezing from generic bypassing), the dying flag is checked before entering queue, and Tejun converts the checking into .mq_freeze_depth, and assumes the counter is increased just after dying flag is set. Unfortunately we doesn't do that in blk_set_queue_dying(). This patch calls blk_freeze_queue_start() in blk_set_queue_dying(), so that we can block new I/O coming once the queue is set as dying. Given blk_set_queue_dying() is always called in remove path of block device, and queue will be cleaned up later, we don't need to worry about undoing the counter. Cc: Tejun Heo <tj@kernel.org> Reviewed-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
Johannes Thumshirn <jthumshirn@suse.de> Reviewed-by:
-
Ming Lei authored
As the .q_usage_counter is used by both legacy and mq path, we need to block new I/O if queue becomes dead in blk_queue_enter(). So rename it and we can use this function in both paths. Reviewed-by:
-
