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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 1 Jul 2009 12:05:19 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Hui Zhu <teawater@...il.com>
Cc:	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, 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.

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?

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