Received-SPF: pass (google.com: domain of linux-kernel+bounces-99708-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Received-SPF: Pass (protection.outlook.com: domain of nvidia.com designates
 216.228.117.161 as permitted sender) receiver=protection.outlook.com;
 client-ip=216.228.117.161; helo=mail.nvidia.com; pr=C
Date: Mon, 11 Mar 2024 17:52:31 -0700
From: Nicolin Chen <nicolinc@nvidia.com>
To: Petr =?utf-8?B?VGVzYcWZw61r?= <petr@tesarici.cz>, Michael Kelley
	<mhklinux@outlook.com>
CC: Will Deacon <will@kernel.org>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>, "kernel-team@android.com"
	<kernel-team@android.com>, "iommu@lists.linux.dev" <iommu@lists.linux.dev>,
	Christoph Hellwig <hch@lst.de>, Marek Szyprowski <m.szyprowski@samsung.com>,
	Robin Murphy <robin.murphy@arm.com>, Petr Tesarik
	<petr.tesarik1@huawei-partners.com>, Dexuan Cui <decui@microsoft.com>
Subject: Re: [PATCH v6 4/6] swiotlb: Fix alignment checks when both
 allocation and DMA masks are present
Message-ID: <Ze+nT+4Radnd/iyw@Asurada-Nvidia>
References: <20240308152829.25754-1-will@kernel.org>
 <20240308152829.25754-5-will@kernel.org>
 <20240311210507.217daf8b@meshulam.tesarici.cz>
 <SN6PR02MB41576E58DDF5A56FC6FC1EB6D4242@SN6PR02MB4157.namprd02.prod.outlook.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <SN6PR02MB41576E58DDF5A56FC6FC1EB6D4242@SN6PR02MB4157.namprd02.prod.outlook.com>
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Mar 2024 00:52:51.8923
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a75a6d77-22b9-4bda-f791-08dc422ebf28
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=43083d15-7273-40c1-b7db-39efd9ccc17a;Ip=[216.228.117.161];Helo=[mail.nvidia.com]
X-MS-Exchange-CrossTenant-AuthSource:
	BN1PEPF0000468B.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB7555

On Mon, Mar 11, 2024 at 09:36:10PM +0000, Michael Kelley wrote:
> From: Petr Tesařík <petr@tesarici.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