linux-kernel - Re: [????] Re: [????] Re: divide error in x86 and cputime

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: <20250708021703.GD15787@redhat.com>
Date: Tue, 8 Jul 2025 04:17:04 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: "Li,Rongqing" <lirongqing@...du.com>,
	Peter Zijlstra <peterz@...radead.org>,
	David Laight <david.laight.linux@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"vschneid@...hat.com" <vschneid@...hat.com>,
	"mgorman@...e.de" <mgorman@...e.de>,
	"bsegall@...gle.com" <bsegall@...gle.com>,
	"dietmar.eggemann@....com" <dietmar.eggemann@....com>,
	"vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
	"juri.lelli@...hat.com" <juri.lelli@...hat.com>,
	"mingo@...hat.com" <mingo@...hat.com>
Subject: Re: [????] Re: [????] Re: divide error in x86 and cputime

On 07/07, Steven Rostedt wrote:
>
> On Tue, 8 Jul 2025 01:58:00 +0000
> "Li,Rongqing" <lirongqing@...du.com> wrote:
>
> > But mul_u64_u64_div_u64() for x86 should not trigger a division error panic,
> maybe should return a ULLONG_MAX on #DE (like non-x86 mul_u64_u64_div_u64(),)
>
> Perhaps.

So do you think

	static inline u64 mul_u64_u64_div_u64(u64 a, u64 mul, u64 div)
	{
		int ok = 0;
		u64 q;

		asm ("mulq %3; 1: divq %4; movl $1,%1; 2:\n"
			_ASM_EXTABLE(1b, 2b)
			: "=a" (q), "+r" (ok)
			: "a" (a), "rm" (mul), "rm" (div)
			: "rdx");

		return ok ? q : -1ul;
	}

makes sense at least for consistency with the generic implementation
in lib/math/div64.c ?

>  But it is still producing garbage.

Agreed. And not a solution to this particular problem.

Oleg.