linux-kernel - Re: BISECTED: Re: source line numbers with x86

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]

Date:	Tue, 27 Jan 2009 11:38:00 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Mike Snitzer <snitzer@...il.com>
Cc:	Dave Anderson <anderson@...hat.com>,
	Andi Kleen <andi@...stfloor.org>,
	Bernhard Walle <bwalle@...e.de>, Ingo Molnar <mingo@...e.hu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	crash-utility@...hat.com
Subject: Re: BISECTED: Re: source line numbers with x86_64 modules?

Mike Snitzer <snitzer@...il.com> writes:

> [I've trimmed the wide cc distribution that was inherited when I
> forked a different thread]
>
> On Mon, Jan 12, 2009 at 10:19 PM, Eric W. Biederman
> <ebiederm@...ssion.com> wrote:
>> "Mike Snitzer" <snitzer@...il.com> writes:
>>>
>>> Now if only I could fix line numbers when debugging crashes in x86_64
>>> modules with the crash utility! :)
>>
>> It's a userspace problem...
>>
>> All of the little usability things are userspace problems.
>>
>> I won't claim that it is trivial because it is a userspace problem, at the
> same
>> time there is no reason to wait for any kernel features to merge etc.  Someone
>> just has to scratch an itch and go fix it.
>
> Yes, the crash utility (userspace) is clearly having problems getting
> line number for symbols in x86_64 modules.  But I finally took some
> time to bisect the point in the kernel where the crash utility first
> started to fail, it appears to be:
>
> commit 7460ed2844ffad7141e30271c0c3da8336e66014
> Author: john stultz <johnstul@...ibm.com>
> Date:   Fri Feb 16 01:28:21 2007 -0800
>
> I used version 4.0-7.6 of the crash utility to test if each commit was
> good or bad.  I simply checked if ext3's module had correct line
> number info for the ext3_get_blocks_handle symbol with: sym
> ext3_get_blocks_handle

Weird.  That patch doesn't appear to affect anything in that area.
So my stab in the dark is that there is something in vmlinux that
crash doesn't know how to cope with.

> I tried to revert 7460ed2844ffad7141e30271c0c3da8336e66014 from
> v2.6.21 but it had conflicts that I've not yet been able to put
> adequate time to resolving.
>
> That aside, I'd be very interested to know how/where this commit is
> impacting the crash utility.  Has alignment of some module metadata
> structure been altered and that is the problem?  This isn't my area of
> expertise but I have to believe others may have useful insight.

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