The module load should fail only if there is something wrong with the
configuration or if an error prevents it to work properly. The module
should be able to be loaded with (nr_device == 0), since it will not
trigger errors or be in malfunction state. Preventing loading with zero
devices also breaks applications that configures this module using
configfs API. Remove the nr_device check to fix this.
Signed-off-by: André Almeida <[email protected]>
Fixes: f7c4ce890dd2 ("null_blk: validate the number of devices")
---
Changes since v1:
- None
---
drivers/block/null_blk_main.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/block/null_blk_main.c b/drivers/block/null_blk_main.c
index ab4b87677139..be32cb5ed339 100644
--- a/drivers/block/null_blk_main.c
+++ b/drivers/block/null_blk_main.c
@@ -1758,10 +1758,6 @@ static int __init null_init(void)
pr_err("null_blk: legacy IO path no longer available\n");
return -EINVAL;
}
- if (!nr_devices) {
- pr_err("null_blk: invalid number of devices\n");
- return -EINVAL;
- }
if (g_queue_mode == NULL_Q_MQ && g_use_per_node_hctx) {
if (g_submit_queues != nr_online_nodes) {
pr_warn("null_blk: submit_queues param is set to %u.\n",
--
2.23.0
Looks good.
Reviewed-by: Chaitanya Kulkarni <[email protected]>
On 09/13/2019 03:04 PM, Andr? Almeida wrote:
> The module load should fail only if there is something wrong with the
> configuration or if an error prevents it to work properly. The module
> should be able to be loaded with (nr_device == 0), since it will not
> trigger errors or be in malfunction state. Preventing loading with zero
> devices also breaks applications that configures this module using
> configfs API. Remove the nr_device check to fix this.
>
> Signed-off-by: Andr? Almeida <[email protected]>
> Fixes: f7c4ce890dd2 ("null_blk: validate the number of devices")
> ---
> Changes since v1:
> - None
> ---
> drivers/block/null_blk_main.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/block/null_blk_main.c b/drivers/block/null_blk_main.c
> index ab4b87677139..be32cb5ed339 100644
> --- a/drivers/block/null_blk_main.c
> +++ b/drivers/block/null_blk_main.c
> @@ -1758,10 +1758,6 @@ static int __init null_init(void)
> pr_err("null_blk: legacy IO path no longer available\n");
> return -EINVAL;
> }
> - if (!nr_devices) {
> - pr_err("null_blk: invalid number of devices\n");
> - return -EINVAL;
> - }
> if (g_queue_mode == NULL_Q_MQ && g_use_per_node_hctx) {
> if (g_submit_queues != nr_online_nodes) {
> pr_warn("null_blk: submit_queues param is set to %u.\n",
>
On 09/13/2019 03:18 PM, Bart Van Assche wrote:
> I just noticed that this patch is necessary to unbreak blktests. The srp
> tests fail as follows with Jens' for-next branch:
>
> modprobe: ERROR: could not insert 'null_blk': Invalid argument
>
> I think that error is triggered by the following statement in
> common/multipath-over-rdma:
>
> modprobe null_blk nr_devices=0 || return $?
>
> Bart.
>
Not only that I'm sure my membacked null_blk testcases will also start
failing without this patch, which I've not posted on mailing list yet.
On 9/13/19 3:02 PM, André Almeida wrote:
> The module load should fail only if there is something wrong with the
> configuration or if an error prevents it to work properly. The module
> should be able to be loaded with (nr_device == 0), since it will not
> trigger errors or be in malfunction state. Preventing loading with zero
> devices also breaks applications that configures this module using
> configfs API. Remove the nr_device check to fix this.
I just noticed that this patch is necessary to unbreak blktests. The srp
tests fail as follows with Jens' for-next branch:
modprobe: ERROR: could not insert 'null_blk': Invalid argument
I think that error is triggered by the following statement in
common/multipath-over-rdma:
modprobe null_blk nr_devices=0 || return $?
Bart.