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]
Date:   Tue, 21 Apr 2020 23:43:24 -0700
From:   Christoph Hellwig <hch@...radead.org>
To:     huobean@...il.com
Cc:     alim.akhtar@...sung.com, avri.altman@....com,
        asutoshd@...eaurora.org, jejb@...ux.ibm.com,
        martin.petersen@...cle.com, stanley.chu@...iatek.com,
        beanhuo@...ron.com, bvanassche@....org, tomas.winkler@...el.com,
        cang@...eaurora.org, linux-scsi@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/5] UFS Host Performance Booster (HPB v1.0) driver

On Thu, Apr 16, 2020 at 10:31:21PM +0200, huobean@...il.com wrote:
> From: Bean Huo <beanhuo@...ron.com>
> 
> Hi,
> I disclose my development/changes on UFS HPB (UFS Host Performance Booster) to
> the community, as this would enable more UFS developers to test and start an
> iterative review and update process.
> 
> The HPB is defined in Jedec Standard Universal Flash (UFS) Host Performance
> Booster (HPB) Extension Version 1.0, which is designed to improve  read
> performance by utilizing the host side memory. Based on our testing, the HPB
> can increase the random read performance by up to about 46% in the random read.
> 
> The original HPB driver is from [1]. Based on it, I did optimizations,
> simplifications, fixed reliability issues, implemented HPB host control mode
> and make it much more readable. which's pushed to here [2] as V1.
> 
> To avoid touching the traditional SCSI core, the HPB driver in this series HPB
> patch chooses to develop under SCSI sub-system layer, and sits the same layer
> with UFSHCD. At the same time, to minimize changes to UFSHCD driver, the HPB
> driver submits its HPB READ BUFFER and HPB WRITE BUFFER requests to the scsi
> device->request_queueu to execute, rather than that directly go through
> raw UPIU request path.

This feature is completley broken, and rather dangerous due to feeding
"physical" addresses looked up by the host in.  I do not think we should
support something that broken in Linux.

Independent of that using two requests in the I/O path is not going
to fly either.  The whole thing seems like an exercise in benchmarketing.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ