linux-kernel - Re: [PATCH 2/3] Add swiotlb offset preserving mapping when dma_dma_parameters->page_offset

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: <20210128173451.GA31631@redsun51.ssa.fujisawa.hgst.com>
Date:   Fri, 29 Jan 2021 02:34:51 +0900
From:   Keith Busch <kbusch@...nel.org>
To:     Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc:     Jianxiong Gao <jxgao@...gle.com>, erdemaktas@...gle.com,
        marcorr@...gle.com, hch@....de, m.szyprowski@...sung.com,
        robin.murphy@....com, gregkh@...uxfoundation.org,
        saravanak@...gle.com, heikki.krogerus@...ux.intel.com,
        rafael.j.wysocki@...el.com, andriy.shevchenko@...ux.intel.com,
        dan.j.williams@...el.com, bgolaszewski@...libre.com,
        jroedel@...e.de, iommu@...ts.linux-foundation.org, axboe@...com,
        sagi@...mberg.me, linux-nvme@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] Add swiotlb offset preserving mapping when
 dma_dma_parameters->page_offset_mask is non zero.

On Thu, Jan 28, 2021 at 12:15:28PM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 27, 2021 at 04:38:28PM -0800, Jianxiong Gao wrote:
> > For devices that need to preserve address offset on mapping through
> > swiotlb, this patch adds offset preserving based on page_offset_mask
> > and keeps the offset if the mask is non zero. This is needed for
> > device drivers like NVMe.
> 
> <scratches his head>
> 
> Didn't you send this patch like a month ago and someone pointed
> out that the right fix would be in the NVMe driver?
> 
> Is there an issue with fixing the NVMe driver?

You got it backwards. The initial "fix" used a flag specific to the nvme
driver, and it was pointed out that it should just be the generic
behaviour.