lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <yq1bljz7y9q.fsf@ca-mkp.ca.oracle.com>
Date:   Wed, 29 Jul 2020 00:32:55 -0400
From:   "Martin K. Petersen" <martin.petersen@...cle.com>
To:     Maxim Levitsky <mlevitsk@...hat.com>
Cc:     "Martin K. Petersen" <martin.petersen@...cle.com>,
        Christoph Hellwig <hch@....de>, linux-kernel@...r.kernel.org,
        Keith Busch <kbusch@...nel.org>,
        Josef Bacik <josef@...icpanda.com>,
        "open list:BLOCK LAYER" <linux-block@...r.kernel.org>,
        Sagi Grimberg <sagi@...mberg.me>, Jens Axboe <axboe@...nel.dk>,
        "open list:NVM EXPRESS DRIVER" <linux-nvme@...ts.infradead.org>,
        "open list:SCSI CDROM DRIVER" <linux-scsi@...r.kernel.org>,
        Tejun Heo <tj@...nel.org>,
        Bart Van Assche <bvanassche@....org>,
        Damien Le Moal <damien.lemoal@....com>,
        Jason Wang <jasowang@...hat.com>,
        Maxim Levitsky <maximlevitsky@...il.com>,
        Stefan Hajnoczi <stefanha@...hat.com>,
        Colin Ian King <colin.king@...onical.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Ajay Joshi <ajay.joshi@....com>,
        Ming Lei <ming.lei@...hat.com>,
        "open list:SONY MEMORYSTICK SUBSYSTEM" <linux-mmc@...r.kernel.org>,
        Satya Tangirala <satyat@...gle.com>,
        "open list:NETWORK BLOCK DEVICE (NBD)" <nbd@...er.debian.org>,
        Hou Tao <houtao1@...wei.com>, Jens Axboe <axboe@...com>,
        "open list:VIRTIO CORE AND NET DRIVERS" 
        <virtualization@...ts.linux-foundation.org>,
        "James E.J. Bottomley" <jejb@...ux.ibm.com>,
        Alex Dubov <oakad@...oo.com>
Subject: Re: [PATCH 02/10] block: virtio-blk: check logical block size


Hi Maxim,

> 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.

My concern is that blk_is_valid_logical_block_size() deviates from the
regular block layer convention where the function to set a given queue
limit will either adjust the passed value or print a warning.

I guess I won't entirely object to having the actual check in a helper
function that drivers with a peculiar initialization pattern can
use. And then make blk_queue_logical_block_size() call that helper as
well to validate the lbs.

But I do think that blk_queue_logical_block_size() should be the
preferred interface and that, where possible, drivers should be updated
to check the return value of that.

-- 
Martin K. Petersen	Oracle Linux Engineering

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ