Re: [patch 0/4] MAP_NOZERO v2 - VM_NOZERO/MAP_NOZERO early summer madness

Davide Libenzi
2007-07-02T23:47:08Z

On Mon, 2 Jul 2007, Rik van Riel wrote:

> Davide Libenzi wrote:
> > On Mon, 2 Jul 2007, Ulrich Drepper wrote:
> >
> > > On 7/2/07, Rik van Riel <riel@redhat.com> wrote:
> > > > That should not happen. The default SELinux configuration
> > > > in Fedora (and Debian?) runs a few daemons in their own
> > > > restricted modes and has most of the system running in
> > > > unconfined_t, including the majority of user programs.
> > > This is the state as of F7. This will change hopefully soon.
> > > Programs like firefox run by normal users must be confined, to. Any
> > > tests using security must be fast, it's not something which is done
> > > only for a few apps.
> >
> > The strong requirement would be that the cookie is not a bit longer than
> > sizeof(unsigned long).
>
> You could easily replace the cookie with a pointer to a free
> page pool.

You talked about this pool even before, but honestly I don't see how it
can help.
Pools requires management (mainly flush under pressure), and it wouldn't
really do any benefit. Don't we already have enough pools in the
allocation path?
The pool has to be UID (or cookie/whatever) based [1], so on top of the
pool lookup/management code, you'll have another lock to be taken (the
pool one). So using the UID (cookie) is simpler, faster and requires no
extra code.
A simple numeric cookie virtually creates "pools" w/out requiring extra
code. Yes, having really separate pool helps the recycle efficency, but
I'm not sure that's worth the extra code.

[1] An mm_struct based pool would be clearly useless

- Davide