Thread (3 messages) 3 messages, 3 authors, 2012-02-08

Re: [RESEND][PATCH] Mark thread stack correctly in proc/<pid>/maps

From: Siddhesh Poyarekar <hidden>
Date: 2012-02-08 04:00:37
Also in: linux-fsdevel, linux-mm, lkml

Possibly related (same subject, not in this thread)

On Sat, Feb 4, 2012 at 12:04 AM, Siddhesh Poyarekar
[off-list ref] wrote:
On Fri, Feb 3, 2012 at 1:31 PM, KOSAKI Motohiro
[off-list ref] wrote:
quoted
The fact is, now process stack and pthread stack clearly behave
different dance. libc don't expect pthread stack grow automatically.
So, your patch will break userland. Just only change display thing.
<snip>
I have also dropped an email on the libc-alpha list here to solicit
comments from libc maintainers on this:

http://sourceware.org/ml/libc-alpha/2012-02/msg00036.html
Kosaki-san, your suggestion of adding an extra flag seems like the
right way to go about this based on the discussion on libc-alpha,
specifically, your point about pthread_getattr_np() -- it may not be a
standard, but it's a breakage anyway. However, looking at the vm_flags
options in mm.h, it looks like the entire 32-bit space has been
exhausted for the flag value. The vm_flags is an unsigned long, so it
ought to take 8 bytes on a 64-bit system, but 32-bit systems will be
left behind.

So there are two options for this:

1) make vm_flags 64-bit for all arches. This will cause ABI breakage
on 32-bit systems, so any external drivers will have to be rebuilt
2) Implement this patch for 64-bit only by defining the new flag only
for 64-bit. 32-bit systems behave as is

Which of these would be better? I prefer the latter because it looks
like the path of least breakage.

-- 
Siddhesh Poyarekar
http://siddhesh.in
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help