(2/7/12 11:00 PM), Siddhesh Poyarekar wrote:
On Sat, Feb 4, 2012 at 12:04 AM, Siddhesh Poyarekar
<siddhesh.poyarekar@xxxxxxxxx> wrote:
On Fri, Feb 3, 2012 at 1:31 PM, KOSAKI Motohiro
<kosaki.motohiro@xxxxxxxxx> wrote:
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
Several month ago, Linus NAKed this way.
2) Implement this patch for 64-bit only by defining the new flag only
for 64-bit. 32-bit systems behave as is
No. That's bad than status quo. Enduser may get inconsistent and bad user
experience.
Now, we are using some bit saving hack. example,
1) use ifdef
#ifndef CONFIG_TRANSPARENT_HUGEPAGE
#define VM_MAPPED_COPY 0x01000000 /* T if mapped copy of data (nommu mmap) */
#else
#define VM_HUGEPAGE 0x01000000 /* MADV_HUGEPAGE marked this vma */
#endif
2) use bit combination
#define VM_STACK_INCOMPLETE_SETUP (VM_RAND_READ | VM_SEQ_READ)
Maybe you can take a similar way. And of course, you can ban some useless flag
bits.
thanks.
Which of these would be better? I prefer the latter because it looks
like the path of least breakage.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
