linux-kernel - Re: [PATCH v6 4/6] swiotlb: Fix alignment checks when both allocation and DMA masks are present

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: <20240312114406.792cc8f9@meshulam.tesarici.cz>
Date: Tue, 12 Mar 2024 11:44:06 +0100
From: Petr Tesařík <petr@...arici.cz>
To: Nicolin Chen <nicolinc@...dia.com>
Cc: Michael Kelley <mhklinux@...look.com>, Will Deacon <will@...nel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "kernel-team@...roid.com" <kernel-team@...roid.com>,
 "iommu@...ts.linux.dev" <iommu@...ts.linux.dev>, Christoph Hellwig
 <hch@....de>, Marek Szyprowski <m.szyprowski@...sung.com>, Robin Murphy
 <robin.murphy@....com>, Petr Tesarik <petr.tesarik1@...wei-partners.com>,
 Dexuan Cui <decui@...rosoft.com>
Subject: Re: [PATCH v6 4/6] swiotlb: Fix alignment checks when both
 allocation and DMA masks are present

On Mon, 11 Mar 2024 17:52:31 -0700
Nicolin Chen <nicolinc@...dia.com> wrote:

> On Mon, Mar 11, 2024 at 09:36:10PM +0000, Michael Kelley wrote:
> > From: Petr Tesařík <petr@...arici.cz>  
> > > I find it somewhat surprising that NVMe does not
> > > in fact require that the NVME_CTRL_PAGE_SHIFT low bits are preserved,
> > > as suggested by Nicolin's successful testing.
> > >
> > > Why is that?  
> > 
> > I saw only one stack trace from Nicolin, and it was file system buffer
> > flushing code that initiated the I/O.  In such cases, it's very likely that the
> > original address is at least 4K aligned.  Hence the offset is zero and
> > the low bits will typically be correct.  
> 
> Though I didn't dig any deeper here, I do see some unaligned
> original addresses passed in at the top level:
>        fsck.ext4-286     [004] .....     2.594190: iommu_dma_map_page: calling swiotlb_tbl_map_single with phys: be750600
>        fsck.ext4-286     [004] .....     2.613032: iommu_dma_map_page: calling swiotlb_tbl_map_single with phys: be780400
>        fsck.ext4-286     [004] .....     2.614096: iommu_dma_map_page: calling swiotlb_tbl_map_single with phys: be7c0600
>        fsck.ext4-286     [004] .....     2.614103: iommu_dma_map_page: calling swiotlb_tbl_map_single with phys: be7e0400
>            mount-288     [005] .....     2.615157: iommu_dma_map_page: calling swiotlb_tbl_map_single with phys: be800400
>       multipathd-405     [003] .....     3.062878: iommu_dma_map_page: calling swiotlb_tbl_map_single with phys: bda40218
>       multipathd-502     [002] .....     3.231721: iommu_dma_map_page: calling swiotlb_tbl_map_single with phys: bd3107b8
>            mount-525     [002] .....     3.250281: iommu_dma_map_page: calling swiotlb_tbl_map_single with phys: bd340200
>       multipathd-529     [004] .....     3.259053: iommu_dma_map_page: calling swiotlb_tbl_map_single with phys: be620478
>       multipathd-571     [005] .....     3.292893: iommu_dma_map_page: calling swiotlb_tbl_map_single with phys: be900328
>       multipathd-580     [005] .....     3.318832: iommu_dma_map_page: calling swiotlb_tbl_map_single with phys: be9207c8

Thank you. Indeed, bit 11 of the physical address was zero in all the
above calls, and that's why it works.

Petr T