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 for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Date:	Fri, 16 Jan 2009 22:22:16 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Eric Paris <eparis@...hat.com>
cc:	LKML <linux-kernel@...r.kernel.org>, linux-acpi@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: WARNING: at kernel/trace/ftrace.c:434 ftrace_bug+0xdb/0x2b1()
 in 2.6.29-rc1-next-20090116


On Fri, 16 Jan 2009, Eric Paris wrote:

> On Fri, 2009-01-16 at 19:47 -0500, Steven Rostedt wrote:
> 
> > And perhaps, if possible, could I get a copy of the vmlinux that was 
> > built, and a CONFIG to go with it.
> 
> So I didn't see it when I rebuilt without any of my patch stack, I'm
> trying to build them back in to see if it was one of mine....

I'm looking at the dump of the vmlinux, and here's something that is 
interesting:

  0x815d45e0 19132281 ffffffff f9132281 ffffffff ..".......".....
  0x815d45f0 51152281 ffffffff 7e152281 ffffffff Q.".....~.".....
  0x815d4600 b0152281 ffffffff e2152281 ffffffff ..".......".....
  0x815d4610 0b162281 ffffffff 42162281 ffffffff ..".....B.".....
  0x815d4620 d8162281 ffffffff 33172281 ffffffff ..".....3.".....
  0x815d4630 26182281 ffffffff 21192281 ffffffff &.".....!.".....
  0x815d4640 091d2281 ffffffff 3f1d2281 ffffffff ..".....?.".....
  0x815d4650 94232281 ffffffff 1d242281 ffffffff .#"......$".....
  0x815d4660 c1242281 ffffffff 0d252281 ffffffff .$"......%".....
  0x815d4670 56252281 ffffffff 1d262281 ffffffff V%"......&".....
  0x815d4680 9f262281 ffffffff ef272281 ffffffff .&"......'".....
  0x815d4690 06282281 ffffffff 2a282281 ffffffff .(".....*(".....
  0x815d46a0 d82c2281 ffffffff fd2c2281 ffffffff .,"......,".....
  0x815d46b0 342d2281 ffffffff 942d2281 ffffffff 4-"......-".....
  0x815d46c0 f32f2281 ffffffff 5c302281 ffffffff ./".....\0".....
  0x815d46d0 12312281 ffffffff 9f312281 ffffffff .1"......1".....
  0x815d46e0 3d322281 ffffffff 62322281 ffffffff =2".....b2".....
  0x815d46f0 87322281 ffffffff ac322281 ffffffff .2"......2".....
  0x815d4700 de322281 ffffffff b6332281 ffffffff .2"......3".....
  0x815d4710 df342281 ffffffff 51152281 ffffffff .4".....Q.".....
  0x815d4720 7e152281 ffffffff b0152281 ffffffff ~.".......".....
  0x815d4730 e2152281 ffffffff 0b162281 ffffffff ..".......".....
  0x815d4740 42162281 ffffffff d8162281 ffffffff B.".......".....
  0x815d4750 33172281 ffffffff 26182281 ffffffff 3.".....&.".....
  0x815d4760 21192281 ffffffff 091d2281 ffffffff !.".......".....
  0x815d4770 3f1d2281 ffffffff 94232281 ffffffff ?."......#".....
  0x815d4780 1d242281 ffffffff c1242281 ffffffff .$"......$".....
  0x815d4790 0d252281 ffffffff 56252281 ffffffff .%".....V%".....
  0x815d47a0 1d262281 ffffffff 9f262281 ffffffff .&"......&".....
  0x815d47b0 ef272281 ffffffff 06282281 ffffffff .'"......(".....
  0x815d47c0 2a282281 ffffffff d82c2281 ffffffff *("......,".....
  0x815d47d0 fd2c2281 ffffffff 342d2281 ffffffff .,".....4-".....
  0x815d47e0 942d2281 ffffffff f32f2281 ffffffff .-"....../".....
  0x815d47f0 5c302281 ffffffff 12312281 ffffffff \0"......1".....
  0x815d4800 9f312281 ffffffff 3d322281 ffffffff .1".....=2".....
  0x815d4810 62322281 ffffffff 87322281 ffffffff b2"......2".....
  0x815d4820 ac322281 ffffffff de322281 ffffffff .2"......2".....
  0x815d4830 b6332281 ffffffff df342281 ffffffff .3"......4".....
  0x815d4840 9d352281 ffffffff c1352281 ffffffff .5"......5".....


The entries from 0x815d45f0 to 0x815d4710 are identical to the entries 
from 0x815d4711 to 0x815d4831. Due to the history of the code, the entries 
are added first into a link list, and then the addresses are modifed in 
reverse order. Since b6332281 ffffffff was last (executed first) it was 
the first one to see the change.

I'm betting that you had an old version of the thermal.o that had the 
mcount_loc already in, and somehow had the recordmcount.o executed again 
on it, creating a duplicate copy. This would cause such an error. By 
rebuilding the whole tree, you fixed things up.

-- Steve

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ