linux-kernel - Re: [Bug 8501] udivdi3 absence with gcc-4.3.0 on kernels 2.6.20.11 & 2.6.22.-rc1

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: <57324fd6fd39b00a9eb1889343fa0330@kernel.crashing.org>
Date:	Sat, 19 May 2007 01:39:43 +0200
From:	Segher Boessenkool <segher@...nel.crashing.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	malitzke@...ronets.com, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"bugme-daemon@...nel-bugs.osdl.org" 
	<bugme-daemon@...zilla.kernel.org>
Subject: Re: [Bug 8501] udivdi3  absence with gcc-4.3.0 on kernels 2.6.20.11 & 2.6.22.-rc1

> gcc-4.3 appears to have cunningly converted this:
>
> static inline void timespec_add_ns(struct timespec *a, u64 ns)
> {
> 	ns += a->tv_nsec;
> 	while(unlikely(ns >= NSEC_PER_SEC)) {
> 		ns -= NSEC_PER_SEC;
> 		a->tv_sec++;
> 	}
> 	a->tv_nsec = ns;
> }
>
> into a divide-by-1000000000 operation, so it emits a call to udivdi3 
> and we
> don't link.

Exactly.  It obviously is a bug in the kernel that it depends
on certain compiler optimisations that it doesn't have direct
control over to happen or not.  OTOH, GCC's behaviour here is
probably a non-optimal code issue; it doesn't seem to take the
unlikely() into account when doing the loop transform.

> I expect that this optimisation will remain in gcc-4.3

If someone files a *useable* problem report it most likely
will be taken care of, actually.

> and we'll end up
> having major kernel releases which don't build on i386 with major gcc
> releases, which isn't altogether desirable.

Yeah, like 4.2.0 with powerpc.  Seems like no one tested it :-(

> I suspect we'll need to fix this
> fairly urgently, and to backport the fix into a number of kernel 
> releases.

If it is 4.3 only, you could instead try to work *with* the GCC
people.  It _is_ very fragile code of course, it wouldn't hurt
to replace it with something better.

> We use the above idiom in several places.  A suitable fix might be to 
> hunt
> down those various sites and then make them call a helper function 
> which
> does
>
> 	if (unlikely(ns >= NSEC_PER_SEC)) {
> 		do_div(...)
> 	}
>
> (Better would be to inline the comparison and to uninline the do_div(),
> if it's a 32-bit arch.  Doing all this in a backportable fashion may
> prove tricky)

Perhaps putting a compiler barrier in there would be enough -- like
an empty asm() that takes the loop variable as input.


Segher

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/