linux-kernel - Re: [BUG] vmlinux.o: warning: objtool: iommu_dma_sw_msi() falls through to next function alloc_io_pgtable

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: <88ef4efd-9736-4c37-9b05-212e65602322@paulmck-laptop>
Date: Wed, 26 Mar 2025 16:45:52 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Josh Poimboeuf <jpoimboe@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>
Cc: linux-kernel@...r.kernel.org, Robin Murphy <robin.murphy@....com>,
	iommu@...ts.linux.dev
Subject: Re: [BUG] vmlinux.o: warning: objtool: iommu_dma_sw_msi() falls
 through to next function alloc_io_pgtable_ops()

On Wed, Mar 26, 2025 at 04:18:51PM -0700, Paul E. McKenney wrote:
> Hello!
> 
> Building next-20250326 using clang version 19.1.7 (CentOS 19.1.7-1.el9)
> gets me the following warning:

Apologies, but make that gcc version 11.5.0 20240719 (Red Hat 11.5.0-5) (GCC).
(Hey, it has almost always been clang in the past...)

Also, the runs that have this problem are the ones whose kernels are
built with CONFIG_DEBUG_LOCK_ALLOC=y, but that do *not* enable KASAN.
For rcutorture, these are scenarios SRCU-P, TREE02, TREE05, TASKS01,
TRACE02, RUDE01, SRCU-T, and TINY02.

							Thanx, Paul

> vmlinux.o: warning: objtool: iommu_dma_sw_msi() falls through to next function alloc_io_pgtable_ops()
> 
> This surprised me for a couple of reasons.  First, from what I
> can see, iommu_dma_sw_msi() does not fall through.  Second, it
> is in drivers/iommu/dma-iommu.c while alloc_io_pgtable_ops() is in
> drivers/iommu/io-pgtable.c, though maybe the compiler and/or linker saw
> fit to rearrange these functions' object code.
> 
> Please let me know of any debug patches or fixes that I could apply,
> or any additional information that you might need.
> 
> 						Thanx, Paul
> 
> Note to self: Run 2025.03.26-14.37.10-remote on first test system.  ;-)
> 
> ------------------------------------------------------------------------
> 
> int iommu_dma_sw_msi(struct iommu_domain *domain, struct msi_desc *desc,
> 		     phys_addr_t msi_addr)
> {
> 	struct device *dev = msi_desc_to_dev(desc);
> 	const struct iommu_dma_msi_page *msi_page;
> 
> 	if (!has_msi_cookie(domain)) {
> 		msi_desc_set_iommu_msi_iova(desc, 0, 0);
> 		return 0;
> 	}
> 
> 	iommu_group_mutex_assert(dev);
> 	msi_page = iommu_dma_get_msi_page(dev, msi_addr, domain);
> 	if (!msi_page)
> 		return -ENOMEM;
> 
> 	msi_desc_set_iommu_msi_iova(desc, msi_page->iova,
> 				    ilog2(cookie_msi_granule(domain)));
> 	return 0;
> }