linux-kernel - Re: [PATCH 1/1] scsi: sd: use max_xfer_blocks for set rw_max if max_xfer

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <20210126035927.4768-1-nanich.lee@samsung.com>
Date:   Tue, 26 Jan 2021 12:59:27 +0900
From:   Changheun Lee <nanich.lee@...sung.com>
To:     martin.petersen@...cle.com, Damien.LeMoal@....com
Cc:     arnd@...db.de, hch@....de, jejb@...ux.ibm.com,
        jisoo2146.oh@...sung.com, junho89.kim@...sung.com,
        linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
        michael.christie@...cle.com, mj0123.lee@...sung.com,
        nanich.lee@...sung.com, oneukum@...e.com,
        seunghwan.hyun@...sung.com, sookwan7.kim@...sung.com,
        woosung2.lee@...sung.com, yt0928.kim@...sung.com
Subject: Re: [PATCH 1/1] scsi: sd: use max_xfer_blocks for set rw_max if
 max_xfer_blocks is available

> Damien,
> 
> >> How about set larger valid value between sdkp->max_xfer_blocks,
> >> and sdkp->opt_xfer_blocks to rw_max?
> >
> > Again, if your device reports an opt_xfer_blocks value that is too
> > small for its own good, that is a problem with this device.
> 
> Correct. It is very much intentional that we do not default to issuing
> the largest commands supported by the physical hardware.
> 
> If the device is not reporting an optimal transfer size, and the block
> layer default is too small, the solution is to adjust max_sectors_kb in
> sysfs (by adding a udev rule, for instance).
>

Sorry, I said wrong.
As others mentioned, it's device problem if opt_xfer_blocks is wrong.
kernel modification is not needed for it.

I want to discuss using max_xfer_blocks instead of opt_xfer_blocks as a optional.
For example, device reports opt_xfer_blocks is 512KB and 1MB as a
max_xfer_blocks too. Currently rw_max is set with 512KB only.
I want a option to select max_xfer_blocks for rw_max.
Are there any historical problem when rw_max is set with max_xfer_blocks?

How about below approach if max_xfer_blocks can be set to rw_max?
It's using queue flag as a option. Do you have good idea to suggest?

static bool sd_validate_max_xfer_size(struct scsi_disk *sdkp,
				      unsigned int dev_max)
{
	struct request_queue *q = sdkp->disk->queue;

	if (!blk_queue_allow_sd_rw_max(q))
		return false;

	if (sdkp->max_xfer_blocks == 0)
		return false;

        ......

	return true;
}

static int sd_revalidate_disk(struct gendisk *disk)
{
	......

	if (sd_validate_max_xfer_size(sdkp, dev_max)) {
		q->limits.io_opt = logical_to_bytes(sdp, sdkp->max_xfer_blocks);
		rw_max = logical_to_sectors(sdp, sdkp->max_xfer_blocks);
	} else if (sd_validate_opt_xfer_size(sdkp, dev_max)) {
		q->limits.io_opt = logical_to_bytes(sdp, sdkp->opt_xfer_blocks);
		rw_max = logical_to_sectors(sdp, sdkp->opt_xfer_blocks);
	} else {
	
	......
}

> -- 
> Martin K. Petersen	Oracle Linux Engineering