linux-kernel - Re: [PATCH] Fix the multithread program core thread message error

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: <20090703094825.GJ5880@cr0.nay.redhat.com>
Date:	Fri, 3 Jul 2009 17:48:25 +0800
From:	Amerigo Wang <xiyou.wangcong@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Hui Zhu <teawater@...il.com>, xiyou.wangcong@...il.com,
	linux-kernel@...r.kernel.org, viro@...iv.linux.org.uk,
	dhowells@...hat.com, Russell King <rmk@....linux.org.uk>,
	linux-arm-kernel@...ts.arm.linux.org.uk, stable@...nel.org
Subject: Re: [PATCH] Fix the multithread program core thread message error

On Wed, Jul 01, 2009 at 12:05:19PM -0700, Andrew Morton wrote:
>On Wed, 1 Jul 2009 14:21:37 +0800
>Hui Zhu <teawater@...il.com> wrote:
>
>> Thanks for your help, Amerigo.
>> 
>> Hui
>> 
>> Fix the multithread program core thread message error.
>> This issue just affect arch with neither has CORE_DUMP_USE_REGSET
>> nor ELF_CORE_COPY_TASK_REGS, ARM is one of them.
>> The thread message of core file is generated in
>> elf_dump_thread_status.  The register values is set by
>> elf_core_copy_task_regs in this function.
>> If a arch doesn't define ELF_CORE_COPY_TASK_REGS, The function
>> elf_core_copy_task_regs will do nothing.  Then the core file will
>> not have the register message of thread.
>> So add elf_core_copy_regs to set regiser values if
>> ELF_CORE_COPY_TASK_REGS doesn't define.
>> The following is how to reproduce this issue:
>>
>> ...
>>
>> Without the patch:
>> (gdb) info threads
>>  3 process 909  0x00000000 in ?? ()
>>  2 process 908  0x00000000 in ?? ()
>> * 1 process 907  0x4a6e2238 in raise () from /lib/libc.so.6
>> You can found that the pc of 909 and 908 is 0x00000000.
>> With the patch:
>> (gdb) info threads
>>  3 process 885  0x4a749974 in nanosleep () from /lib/libc.so.6
>>  2 process 884  0x4a749974 in nanosleep () from /lib/libc.so.6
>> * 1 process 883  0x4a6e2238 in raise () from /lib/libc.so.6
>> The pc of 885 and 884 is right.
>

Thanks for taking this.


>I'm trying to work out if we should backport this fix into earlier
>kernels (2.6.30.x, 2.6.29.x, etc).
>
>I'd have though that having gdb produce crap for all the threads would
>be fairly irritating to ARM developers and hence we should backport
>this.  But perhaps it doens't affect many people, dunno.
>
>What do poeple think?

This doesn't affect many platforms, only the platforms which has
_neither_ CORE_DUMP_USE_REGSET nor ELF_CORE_COPY_TASK_REGS.

I haven't checked all, just x86 and arm, x86 doesn't, arm does.


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