Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp688858ybh; Tue, 21 Jul 2020 05:43:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxOwFMuXVwW5HRcw7ty6nYoVWEOaME0U+4m3AUxgH1N6ZOnesGbLTSdP5usRCkb3XeWfCUd X-Received: by 2002:a05:6402:31bb:: with SMTP id dj27mr25745337edb.387.1595335397015; Tue, 21 Jul 2020 05:43:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595335397; cv=none; d=google.com; s=arc-20160816; b=Kenxi2FtqYOF9rdgSRSvfcnMi9vaJro+Up9nuq7UvuvJ3LdlOn6hxJfa84ogtpbP5n kE4OpRBNhpgSSk1wQpcTHmN80nKOBGy2OxIqpbWFn0iLswYBQicL9p8v+LvgPYJa2rK7 RZvDCsyy8DvIACq2w58A+ujHKalZjT+DXLkaJrOi4RejpPAkvTogev+Qi/cHDSCdJnTI 4+OKaAuriET3fI6nT1cC2YD3ygPpuksa0/tKz2m+NmUZX6ptT10HF0wNBJUNG6fP76OD jyf3qJzkKoPO+kmJexK669gITZuY6OKINolGUt8Oa4xC1gpA3O5zR80wRDGdtObyfKe1 9AMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=sxEWR5e+zFYMBJOOuaa+SYdRZddlN9HI1DKBH6wob58=; b=F0FxGks3qcyV+CJO6HQ4zlBuanM3lKIjMLxil9VJnRBarYM9LRhCypoVKC7WPqW9nl K/p5csGnMTl9l3xGG1PUXiruqKRMh2Nzr222Di8Mp6s2ScFMAugW2++OOzGabFXqnwMl SekRNqK4h7sR1cH5LSIXSvoM8iWrduKR6LnglpuLt+wp8JCHyBiI7VwXXTNAccjfuB13 66hR2qgQ2/bLfCLVml9eghbq7IBARu2J32n1is2o7wUcswEVMZbHXjvbL6+XFGfvipfI VVZKU+cOJVS/BPITQm3C+YdGIcw3FxyaIjv8MPZc2junkl+AIuvoU7YXsrMGV2cT9a8m c28g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ZRTvmXSz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gh11si12515638ejb.442.2020.07.21.05.42.54; Tue, 21 Jul 2020 05:43:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ZRTvmXSz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729166AbgGUMmY (ORCPT + 99 others); Tue, 21 Jul 2020 08:42:24 -0400 Received: from us-smtp-1.mimecast.com ([207.211.31.81]:41200 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726904AbgGUMmX (ORCPT ); Tue, 21 Jul 2020 08:42:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1595335342; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sxEWR5e+zFYMBJOOuaa+SYdRZddlN9HI1DKBH6wob58=; b=ZRTvmXSz7Rh+hPT0fQAvmYiDjwXPM+ti/tOaKzGp6FVMRz3Q8Lekog1wEFY1v5wTpHRbCU 2OMkIf4g9pOflXTvHshxcY2cM+IbyRmobhCZagQiDqJWzOWJNgtME82sR1DHPhavU4NLrb 10M9jw4Q3LVcUFTB0Ugkeu9TBwUgooI= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-263--3BfRSnxPBiIkZC8r_aHkQ-1; Tue, 21 Jul 2020 08:42:20 -0400 X-MC-Unique: -3BfRSnxPBiIkZC8r_aHkQ-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 35D7780047E; Tue, 21 Jul 2020 12:42:16 +0000 (UTC) Received: from starship (unknown [10.35.206.163]) by smtp.corp.redhat.com (Postfix) with ESMTP id A1F9870105; Tue, 21 Jul 2020 12:42:08 +0000 (UTC) Message-ID: <435f1c04b58bd2298be3166b7bab458640927118.camel@redhat.com> Subject: Re: [PATCH 05/10] block: null: use blk_is_valid_logical_block_size From: Maxim Levitsky To: Damien Le Moal , "linux-kernel@vger.kernel.org" Cc: Keith Busch , Josef Bacik , "open list:BLOCK LAYER" , Sagi Grimberg , Jens Axboe , "open list:NVM EXPRESS DRIVER" , "open list:SCSI CDROM DRIVER" , Tejun Heo , Bart Van Assche , "Martin K. Petersen" , Jason Wang , Maxim Levitsky , Stefan Hajnoczi , Colin Ian King , "Michael S. Tsirkin" , Paolo Bonzini , Ulf Hansson , Ajay Joshi , Ming Lei , "open list:SONY MEMORYSTICK SUBSYSTEM" , Christoph Hellwig , Satya Tangirala , "open list:NETWORK BLOCK DEVICE (NBD)" , Hou Tao , Jens Axboe , "open list:VIRTIO CORE AND NET DRIVERS" , "James E.J. Bottomley" , Alex Dubov Date: Tue, 21 Jul 2020 15:42:07 +0300 In-Reply-To: References: <20200721105239.8270-1-mlevitsk@redhat.com> <20200721105239.8270-6-mlevitsk@redhat.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.3 (3.36.3-1.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2020-07-21 at 11:15 +0000, Damien Le Moal wrote: > On 2020/07/21 19:54, Maxim Levitsky wrote: > > This slightly changes the behavier of the driver, > > s/behavier/behavior Thanks. This is one of the typos I make very consistently. > > > when given invalid block size (non power of two, or below 512 bytes), > > but shoudn't matter. > > > > Signed-off-by: Maxim Levitsky > > --- > > drivers/block/null_blk_main.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/block/null_blk_main.c b/drivers/block/null_blk_main.c > > index 87b31f9ca362e..e4df4b903b90b 100644 > > --- a/drivers/block/null_blk_main.c > > +++ b/drivers/block/null_blk_main.c > > @@ -1684,8 +1684,8 @@ static int null_init_tag_set(struct nullb *nullb, struct blk_mq_tag_set *set) > > > > static int null_validate_conf(struct nullb_device *dev) > > { > > - dev->blocksize = round_down(dev->blocksize, 512); > > - dev->blocksize = clamp_t(unsigned int, dev->blocksize, 512, 4096); > > + if (!blk_is_valid_logical_block_size(dev->blocksize)) > > + return -ENODEV; > > > > if (dev->queue_mode == NULL_Q_MQ && dev->use_per_node_hctx) { > > if (dev->submit_queues != nr_online_nodes) > > @@ -1865,7 +1865,7 @@ static int __init null_init(void) > > struct nullb *nullb; > > struct nullb_device *dev; > > > > - if (g_bs > PAGE_SIZE) { > > + if (!blk_is_valid_logical_block_size(g_bs)) { > > pr_warn("invalid block size\n"); > > pr_warn("defaults block size to %lu\n", PAGE_SIZE); > > g_bs = PAGE_SIZE; > > Not sure if this change is OK. Shouldn't the if here be kept as is and > blk_is_valid_logical_block_size() called after it to check values lower than 4K ? The thing is that this driver supports two ways of creating the block devices. On module load it creates by default a single block device and it uses g_bs as its block size, but then it also has configfs based interface that allows to create more block devices. The default is taken also from g_bs but then user can change it ( via those NULLB_DEVICE_ATTR wrappers) I changed the behavior slightly, that now if user supplies bad value, it will be rejected instead of finding closest valid value. In addition to that there is very small bug that didn't bother to fix in this series (but I will in next one). The bug is that when null_validate_conf fails, it return value is overriden with -ENOMEM, which gives the user a wrong error message. Thanks for the review! Best regards, Maxim Levitsky > >