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: <Ze+nT+4Radnd/iyw@Asurada-Nvidia>
Date: Mon, 11 Mar 2024 17:52:31 -0700
From: Nicolin Chen <nicolinc@...dia.com>
To: Petr Tesařík <petr@...arici.cz>, Michael Kelley
	<mhklinux@...look.com>
CC: 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, 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

Or is that a different "original address"?

Thanks
Nicolin