tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: __ps_strings and compat32
On Wed, Jan 05, 2011 at 02:56:05AM +0000, Christos Zoulas wrote:
> In article <20110104120934.GA30484%britannica.bec.de@localhost>,
> Joerg Sonnenberger <joerg%britannica.bec.de@localhost> wrote:
> >Hi all,
> >while investigating ways to access the auxillary vector, I found that we
> >currently don't deal correctly with struct ps_strings in 32bit compat.
> >This structure is placed by the kernel into the initial stack and
> >referenced in userland by __ps_strings. It is used by setproctitle(3)
> >and therefore e.g. by programs that want to include a status report in
> >the ps(1) output. This naturally works only by chance, if at all in
> >compat32. How do we want to deal with it?
> >
> >Variant 1: Leave it as broken. It should be said that having reliable
> >ps_strings could speed up ld.elf_so a bit.
> >
> >Variant 2: Introduce two methods for obtaining and setting ps_strings of
> >a specific process and hook those into the normal exec mechanism. This
> >would in theory allow emulations pretty arbitrary data structures.
> >
> >Other options that are better?
>
> Something like a mapped page for each process to store:
>
> - thread id
> - clock
> - optimized memcpy/memmove/memset for the processor
> - ps_string info
>
> etc. This could be mapped at a known location.
Thread is is not a process property.
ps_string is a global property, but moving it into some magic area
doesn't help compat.
memcpy/... can already be obtained with ld.so.conf, so I am not sure how
much that really belongs in this either.
In short, what can be done with a comm page is a separate topic, but I
don't see how it actually fixes the problem in my original mail.
Joerg
Home |
Main Index |
Thread Index |
Old Index