linux-kernel - Re: Fedora's latest gcc produces unbootable kernels

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: <23803.203.197.163.97.1196669842.squirrel@www.tglx.de>
Date:	Mon, 3 Dec 2007 09:17:22 +0100 (CET)
From:	Thomas Gleixner <tglx@....tglx.de>
To:	"Pierre Ossman" <drzeus-list@...eus.cx>
Cc:	"Pierre Ossman" <drzeus-list@...eus.cx>,
	"LKML" <linux-kernel@...r.kernel.org>, jakub@...hat.com,
	"Thomas Gleixner" <tglx@...utronix.de>
Subject: Re: Fedora's latest gcc produces unbootable kernels

> On Sat, 1 Dec 2007 18:47:52 +0100
> Pierre Ossman <drzeus-list@...eus.cx> wrote:
>> > The latest GCC in Fedora rawhide contains some serious bug (or
>> provokes a latent one in the kernel) that makes every kernel built
>> unbootable. It just locks up halfway through the init. Kernels that
>> previously worked fine all now experience the same symptom. Even RH's
>> own kernels exhibit this. The kernel built Nov 24th works, Nov 26th
>> doesn't. gcc was updated 26th, 14 hours earlier.
>> >
>>
>> Digging a bit further, it is indeed the high-res stuff (the first
>> missing message) that hangs. If I hard code the kernel to just be
>> non-high-res capable, it boots, but time keeping is horribly broken.
>>
>> Anyway, hopefully this means I'll soon have the object file that gets
>> miscompiled. Jakub also pointed me to an older gcc RPM so that I can
>> produce an object file with that as well and see what differs.
>>
>
> I've now pinpointed where it hangs. And it doesn't hang in fact. It gets
> stuck in an infinite loop in tick_setup_sched_timer():
>
> 	for (;;) {
> 		hrtimer_forward(&ts->sched_timer, now, tick_period);
> 		hrtimer_start(&ts->sched_timer, ts->sched_timer.expires,
> 			      HRTIMER_MODE_ABS);
> 		/* Check, if the timer was already in the past */
> 		if (hrtimer_active(&ts->sched_timer))
> 			break;
> 		now = ktime_get();
> 	}
>
> I've added Thomas as cc as this is his domain, so perhaps he has some idea
> what the compiler does wrong here. I've also included the two object files
> (one good, one bad). HEAD is v2.6.24-rc3.

I looked at the disassembly but I can not spot the problem.

I think the real problem is somewhere else. Likely candidates are
hrtimer_forward() or hrtimer_start() - in that order.

Thanks,

      tglx

P.S.: I have restricted network access today, so I can not reproduce my self.

--
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/