linux-kernel - Re: [PATCH v14 06/12] swiotlb: Use is_swiotlb_force

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: <19d4c7a2-744d-21e0-289c-a576e1f0e6f3@quicinc.com>
Date:   Wed, 23 Jun 2021 14:44:34 -0400
From:   Qian Cai <quic_qiancai@...cinc.com>
To:     Will Deacon <will@...nel.org>
CC:     Claire Chang <tientzu@...omium.org>,
        Rob Herring <robh+dt@...nel.org>, <mpe@...erman.id.au>,
        Joerg Roedel <joro@...tes.org>,
        Frank Rowand <frowand.list@...il.com>,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        <boris.ostrovsky@...cle.com>, <jgross@...e.com>,
        Christoph Hellwig <hch@....de>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        <heikki.krogerus@...ux.intel.com>,
        <thomas.hellstrom@...ux.intel.com>, <peterz@...radead.org>,
        <benh@...nel.crashing.org>, <joonas.lahtinen@...ux.intel.com>,
        <dri-devel@...ts.freedesktop.org>, <chris@...is-wilson.co.uk>,
        <grant.likely@....com>, <paulus@...ba.org>, <mingo@...nel.org>,
        <jxgao@...gle.com>, <sstabellini@...nel.org>,
        Saravana Kannan <saravanak@...gle.com>, <xypron.glpk@....de>,
        "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        <bskeggs@...hat.com>, <linux-pci@...r.kernel.org>,
        <xen-devel@...ts.xenproject.org>,
        Thierry Reding <treding@...dia.com>,
        <intel-gfx@...ts.freedesktop.org>, <matthew.auld@...el.com>,
        linux-devicetree <devicetree@...r.kernel.org>, <daniel@...ll.ch>,
        <airlied@...ux.ie>, <maarten.lankhorst@...ux.intel.com>,
        <linuxppc-dev@...ts.ozlabs.org>, <jani.nikula@...ux.intel.com>,
        Nicolas Boichat <drinkcat@...omium.org>,
        <rodrigo.vivi@...el.com>, <bhelgaas@...gle.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        lkml <linux-kernel@...r.kernel.org>,
        "list@....net:IOMMU DRIVERS" <iommu@...ts.linux-foundation.org>,
        Jim Quinlan <james.quinlan@...adcom.com>,
        <thomas.lendacky@....com>, Robin Murphy <robin.murphy@....com>,
        <bauerman@...ux.ibm.com>
Subject: Re: [PATCH v14 06/12] swiotlb: Use is_swiotlb_force_bounce for
 swiotlb data bouncing



On 6/23/2021 2:37 PM, Will Deacon wrote:
> On Wed, Jun 23, 2021 at 12:39:29PM -0400, Qian Cai wrote:
>>
>>
>> On 6/18/2021 11:40 PM, Claire Chang wrote:
>>> Propagate the swiotlb_force into io_tlb_default_mem->force_bounce and
>>> use it to determine whether to bounce the data or not. This will be
>>> useful later to allow for different pools.
>>>
>>> Signed-off-by: Claire Chang <tientzu@...omium.org>
>>> Reviewed-by: Christoph Hellwig <hch@....de>
>>> Tested-by: Stefano Stabellini <sstabellini@...nel.org>
>>> Tested-by: Will Deacon <will@...nel.org>
>>> Acked-by: Stefano Stabellini <sstabellini@...nel.org>
>>
>> Reverting the rest of the series up to this patch fixed a boot crash with NVMe on today's linux-next.
> 
> Hmm, so that makes patch 7 the suspicious one, right?

Will, no. It is rather patch #6 (this patch). Only the patch from #6 to #12 were reverted to fix the issue. Also, looking at this offset of the crash,

pc : dma_direct_map_sg+0x304/0x8f0
is_swiotlb_force_bounce at /usr/src/linux-next/./include/linux/swiotlb.h:119

is_swiotlb_force_bounce() was the new function introduced in this patch here.

+static inline bool is_swiotlb_force_bounce(struct device *dev)
+{
+	return dev->dma_io_tlb_mem->force_bounce;
+}

> 
> Looking at that one more closely, it looks like swiotlb_find_slots() takes
> 'alloc_size + offset' as its 'alloc_size' parameter from
> swiotlb_tbl_map_single() and initialises 'mem->slots[i].alloc_size' based
> on 'alloc_size + offset', which looks like a change in behaviour from the
> old code, which didn't include the offset there.
> 
> swiotlb_release_slots() then adds the offset back on afaict, so we end up
> accounting for it twice and possibly unmap more than we're supposed to?
> 
> Will
>