Am 28.01.2010 um 22:58 schrieb Linus Torvalds:
>>> I don't get a core-dump, even though it says I do:
>>>
>>> 	[torvalds@nehalem amd64_killer]$ ./run.sh
>>> 	* look at /proc/22768/maps and press enter to continue...
>>> 	* executing ./poison...
>>> 	* that failed (No such file or directory), as expected :)
>>> 	* look at /proc/22768/maps and press enter to continue...
>>
>> Have you looked at /proc/PID/maps at this point? On our machine  
>> the [vdso] was
>> gone and [vsyscall] was there instead -- at an 64 bit address of  
>> course.
>
> Yup. That's the behavior I see - except I see the [vdso] thing in both
> cases.
>
> So I agree that it has become a 64-bit process, and that the whole
> personality crap is buggy.

So it's not really fixed yet :)

> I just don't see the crash.

This at least gives us the hint, the core writing code maybe was  
modified in a way it does some additionally check that prevents the  
kernel to crash in this case. But the crash should be reproducible on  
the latest stable, 2.6.32.6 -- at least this is what I would read out  
of the statement of hpa made.

>> Since this is a production server I would rather stick to a stable  
>> kernel and
>> just pick the commit that fixes the issue. Can you please tell me  
>> which one
>> that may be?
>
> I'd love to be able to say that it's been fixed in so-and-so, but  
> since I
> don't know what the oops is, I have a hard time even guessing  
> _whether_ it
> has actually been fixed or not, or whether the reason I don't see  
> it is
> something else totally unrelated.

I'll look into the last commits to fs/exec.c and see if I can find  
something that suits to my assumption.

Greets,
Mathias