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