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] [day] [month] [year] [list]
Message-ID: <Z5H5gTQa7UEpltMa@ryzen>
Date: Thu, 23 Jan 2025 09:10:41 +0100
From: Niklas Cassel <cassel@...nel.org>
To: Jon Hunter <jonathanh@...dia.com>
Cc: Arnd Bergmann <arnd@...db.de>, Hans Zhang <18255117159@....com>,
	Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
	Krzysztof WilczyƄski <kw@...ux.com>,
	Kishon Vijay Abraham I <kishon@...nel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
	rockswang7@...il.com,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: Re: [v11 2/2] misc: pci_endpoint_test: Fix overflow of bar_size

On Wed, Jan 22, 2025 at 11:18:44AM +0000, Jon Hunter wrote:
> 
> On 22/01/2025 10:26, Arnd Bergmann wrote:
> > On Wed, Jan 22, 2025, at 11:07, Niklas Cassel wrote:
> > > On Tue, Jan 21, 2025 at 05:46:43PM +0000, Jon Hunter wrote:
> > > > > diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/>>
> > > > 
> > > > This change breaks building the kernel with GCC v7 and I see ...
> > > > 
> > > > ERROR: modpost: "__aeabi_uldivmod" [drivers/misc/pci_endpoint_test.ko]
> > > > undefined!
> > > > ERROR: modpost: "__aeabi_ldivmod" [drivers/misc/pci_endpoint_test.ko]
> > > > undefined!
> > > > 
> > > > I know that this is an old GCC version, but this is a farm builder and the
> > > > kernel still indicates that GCC v5.1 is still supported [0].
> > > 
> > > do you have any idea what is going on here?
> > > 
> > > I'm a bit puzzled, since looking at other reports of this error,
> > > e.g.:
> > > https://lore.kernel.org/all/20241018151016.3496613-1-arnd@kernel.org/
> > > 
> > > using div_u64() is usually the solution for this problem (for things that
> > > are not performance critical), not the cause of it... any ideas?
> > 
> > I have tried to look at the email thread, but not tried to reproduce
> > it yet. I have two ideas about what might be happening:
> > 
> > a) something causes a /different/ division to call into
> >     __aeabi_uldivmod(), not the one from div_u64().
> > 
> > b) the compiler notices one of the arguments to div_u64() being
> >     constant in some cases and splits the calling function into
> >     two special cases, for both the constant and non-constant
> >     cases. This sometimes confuses the __builtin_constant_p()
> >     in do_div() that decides to fall back to a 32-bit division.
> > 
> > Try looking at the .s file when you run
> > 'make drivers/misc/pci_endpoint_test.s' to see where exactly it
> > calls the two division functions, maybe you see the problem then,
> > otherwise I can try to reproduce it here.
> 
> 
> FWIW I have encountered similar problems with this before with this compiler
> ...
> 
> https://lore.kernel.org/linux-tegra/7733a4ca-330b-4127-af12-33f376fbbc47@nvidia.com/

I had no errors when building this patch using:
gcc (Debian 7.4.0-6) 7.4.0
on i386.

neither with CONFIG_PHYS_ADDR_T_64BIT=y (CONFIG_X86_PAE=y)
nor without it set.

So perhaps this is a bug in gcc 7.x on arm32 or in the arm32
implementation of div_u64() ?


Kind regards,
Niklas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ