linux-kernel - Re: [PATCH] sd: remove redundant check for BLK_DEF_MAX

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: <yq1fusnjazm.fsf@sermon.lab.mkp.net>
Date:	Wed, 08 Jun 2016 23:29:33 -0400
From:	"Martin K. Petersen" <martin.petersen@...cle.com>
To:	Long Li <longli@...rosoft.com>
Cc:	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Tom Yan <tom.ty89@...il.com>,
	"James E.J. Bottomley" <jejb@...ux.vnet.ibm.com>,
	"linux-scsi\@vger.kernel.org" <linux-scsi@...r.kernel.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] sd: remove redundant check for BLK_DEF_MAX_SECTORS

>>>>> "Long" == Long Li <longli@...rosoft.com> writes:

Long,

Long> The problem I'm trying to solve is that, I want to have lower
Long> layer driver to setup max_sectors bigger than
Long> BLK_DEF_MAX_SECTORS.

Capping at BLK_DEF_MAX_SECTORS unless a device has explicitly reported
requirements is intentional. We have not had good experiences with
making I/O requests too big in general. So BLK_DEF_MAX_SECTORS has
deliberately been kept small. However, it was recently bumped to 1MB and
change by default.

Long> n Hyper-v, we use 2MB max transfer I/O size, in future version the
Long> max transfer I/O size will increase to 8MB.

But presumably you provide a BLOCK LIMITS VPD for your virtual targets?

Long> The reason why I think it may not be necessary for sd.c to setup
Long> max_sectors, it's because this value may have already been setup
Long> twice before reaching the code in sd.c: 1. When this disk device
Long> is first scanned, or re-scanned (in scsi_scan.c), where it
Long> eventually calls __scsi_init_queue(), and use the max_sectors in
Long> the scsi_host_template.  2. in slave_configure of
Long> scsi_host_template, when the lower layer driver implements this
Long> function in its template and it can change this value there.

Those cause limits to be set for the controller. We won't know the
device limits until we hit revalidate.

blk_queue_max_hw_sectors() will also clamp the R/W max at
BLK_DEF_MAX_SECTORS, though.

-- 
Martin K. Petersen	Oracle Linux Engineering