Linux-SCSI Archive on lore.kernel.org
 help / color / Atom feed
From: Maxim Levitsky <mlevitsk@redhat.com>
To: "Martin K. Petersen" <martin.petersen@oracle.com>,
	Christoph Hellwig <hch@lst.de>
Cc: linux-kernel@vger.kernel.org, Keith Busch <kbusch@kernel.org>,
	Josef Bacik <josef@toxicpanda.com>,
	"open list:BLOCK LAYER" <linux-block@vger.kernel.org>,
	Sagi Grimberg <sagi@grimberg.me>, Jens Axboe <axboe@kernel.dk>,
	"open list:NVM EXPRESS DRIVER" <linux-nvme@lists.infradead.org>,
	"open list:SCSI CDROM DRIVER" <linux-scsi@vger.kernel.org>,
	Tejun Heo <tj@kernel.org>, Bart Van Assche <bvanassche@acm.org>,
	Damien Le Moal <damien.lemoal@wdc.com>,
	Jason Wang <jasowang@redhat.com>,
	Maxim Levitsky <maximlevitsky@gmail.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Colin Ian King <colin.king@canonical.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Ajay Joshi <ajay.joshi@wdc.com>, Ming Lei <ming.lei@redhat.com>,
	"open list:SONY MEMORYSTICK SUBSYSTEM"
	<linux-mmc@vger.kernel.org>, Satya Tangirala <satyat@google.com>,
	"open list:NETWORK BLOCK DEVICE (NBD)" <nbd@other.debian.org>,
	Hou Tao <houtao1@huawei.com>, Jens Axboe <axboe@fb.com>,
	"open list:VIRTIO CORE AND NET DRIVERS" 
	<virtualization@lists.linux-foundation.org>,
	"James E.J. Bottomley" <jejb@linux.ibm.com>,
	Alex Dubov <oakad@yahoo.com>
Subject: Re: [PATCH 02/10] block: virtio-blk: check logical block size
Date: Wed, 22 Jul 2020 12:11:17 +0300
Message-ID: <f16aba1020019530564f0869a67951282104a5d2.camel@redhat.com> (raw)
In-Reply-To: <yq1zh7sfedj.fsf@ca-mkp.ca.oracle.com>

On Tue, 2020-07-21 at 22:55 -0400, Martin K. Petersen wrote:
> Christoph,
> 
> > Hmm, I wonder if we should simply add the check and warning to
> > blk_queue_logical_block_size and add an error in that case.  Then
> > drivers only have to check the error return, which might add a lot
> > less boiler plate code.
> 
> Yep, I agree.
> 

I also agree that this would be cleaner (I actually tried to implement
this the way you suggest), but let me explain my reasoning for doing it
this way.

The problem is that most current users of blk_queue_logical_block_size
(43 uses in the tree, out of which only 9 use constant block size) check
for the block size relatively early, often store it in some internal
struct etc, prior to calling blk_queue_logical_block_size thus making
them only to rely on blk_queue_logical_block_size as the check for 
block size validity will need non-trivial changes in their code.

Instead of this adding blk_is_valid_logical_block_size allowed me
to trivially convert most of the uses.

For RFC I converted only some drivers that I am more familiar with
and/or can test but I can remove the driver's own checks in most other
drivers with low chance of introducing a bug, even if I can't test the
driver.

What do you think?

I can also both make blk_queue_logical_block_size return an error value,
and have blk_is_valid_logical_block_size and use either of these checks,
depending on the driver with eventual goal of un-exporting
blk_is_valid_logical_block_size.

Also note that I did add WARN_ON to blk_queue_logical_block_size.

Best regards,
	Maxim Levitsky


  reply index

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-21 10:52 [PATCH 00/10] RFC: move logical block size checking to the block core Maxim Levitsky
2020-07-21 10:52 ` [PATCH 01/10] block: introduce blk_is_valid_logical_block_size Maxim Levitsky
2020-07-21 11:05   ` Damien Le Moal
2020-07-21 11:09     ` Maxim Levitsky
2020-07-21 11:31       ` Damien Le Moal
2020-07-21 15:13   ` Christoph Hellwig
2020-07-22  8:50     ` Maxim Levitsky
2020-07-23  9:13   ` [block] 4c873fbf07: WARNING:at_block/blk-settings.c:#blk_queue_logical_block_size kernel test robot
2020-07-21 10:52 ` [PATCH 02/10] block: virtio-blk: check logical block size Maxim Levitsky
2020-07-21 11:07   ` Damien Le Moal
2020-07-21 15:14   ` Christoph Hellwig
2020-07-22  2:55     ` Martin K. Petersen
2020-07-22  9:11       ` Maxim Levitsky [this message]
2020-07-28 14:27         ` Maxim Levitsky
2020-07-29  4:32         ` Martin K. Petersen
2020-07-28 15:44   ` Stefan Hajnoczi
2020-07-21 10:52 ` [PATCH 03/10] block: loop: use blk_is_valid_logical_block_size Maxim Levitsky
2020-07-21 11:08   ` Damien Le Moal
2020-07-21 10:52 ` [PATCH 04/10] block: nbd: " Maxim Levitsky
2020-07-21 11:09   ` Damien Le Moal
2020-07-21 10:52 ` [PATCH 05/10] block: null: " Maxim Levitsky
2020-07-21 11:15   ` Damien Le Moal
2020-07-21 12:42     ` Maxim Levitsky
2020-07-21 10:52 ` [PATCH 06/10] block: ms_block: " Maxim Levitsky
2020-07-21 11:17   ` Damien Le Moal
2020-07-21 10:52 ` [PATCH 07/10] block: mspro_blk: " Maxim Levitsky
2020-07-21 11:17   ` Damien Le Moal
2020-07-21 10:52 ` [PATCH 08/10] block: nvme: " Maxim Levitsky
2020-07-21 11:23   ` Damien Le Moal
2020-07-21 10:52 ` [PATCH 09/10] block: scsi: sd: " Maxim Levitsky
2020-07-21 11:25   ` Damien Le Moal
2020-07-21 12:55     ` Maxim Levitsky
2020-07-21 10:52 ` [PATCH 10/10] block: scsi: sr: " Maxim Levitsky
2020-07-21 11:29   ` Damien Le Moal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f16aba1020019530564f0869a67951282104a5d2.camel@redhat.com \
    --to=mlevitsk@redhat.com \
    --cc=ajay.joshi@wdc.com \
    --cc=axboe@fb.com \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=colin.king@canonical.com \
    --cc=damien.lemoal@wdc.com \
    --cc=hch@lst.de \
    --cc=houtao1@huawei.com \
    --cc=jasowang@redhat.com \
    --cc=jejb@linux.ibm.com \
    --cc=josef@toxicpanda.com \
    --cc=kbusch@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=maximlevitsky@gmail.com \
    --cc=ming.lei@redhat.com \
    --cc=mst@redhat.com \
    --cc=nbd@other.debian.org \
    --cc=oakad@yahoo.com \
    --cc=pbonzini@redhat.com \
    --cc=sagi@grimberg.me \
    --cc=satyat@google.com \
    --cc=stefanha@redhat.com \
    --cc=tj@kernel.org \
    --cc=ulf.hansson@linaro.org \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-SCSI Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-scsi/0 linux-scsi/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-scsi linux-scsi/ https://lore.kernel.org/linux-scsi \
		linux-scsi@vger.kernel.org
	public-inbox-index linux-scsi

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-scsi


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git