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: <yq15z3o9vod.fsf@ca-mkp.ca.oracle.com>
Date:   Fri, 22 Jan 2021 22:38:58 -0500
From:   "Martin K. Petersen" <martin.petersen@...cle.com>
To:     Damien Le Moal <Damien.LeMoal@....com>
Cc:     Changheun Lee <nanich.lee@...sung.com>,
        "arnd@...db.de" <arnd@...db.de>, "hch@....de" <hch@....de>,
        "jejb@...ux.ibm.com" <jejb@...ux.ibm.com>,
        "jisoo2146.oh@...sung.com" <jisoo2146.oh@...sung.com>,
        "junho89.kim@...sung.com" <junho89.kim@...sung.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        "martin.petersen@...cle.com" <martin.petersen@...cle.com>,
        "michael.christie@...cle.com" <michael.christie@...cle.com>,
        "mj0123.lee@...sung.com" <mj0123.lee@...sung.com>,
        "oneukum@...e.com" <oneukum@...e.com>,
        "seunghwan.hyun@...sung.com" <seunghwan.hyun@...sung.com>,
        "sookwan7.kim@...sung.com" <sookwan7.kim@...sung.com>,
        "woosung2.lee@...sung.com" <woosung2.lee@...sung.com>,
        "yt0928.kim@...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).

-- 
Martin K. Petersen	Oracle Linux Engineering