Re: [patch 0/5] Support for sanitization flag in low-level page allocator

[Robin Holt <holt@sgi.com>]

> > Seems like a particularly wasteful use of a pageflag. Why not simply
> > erase the buffer before freeing in those few places where we know its
> > important (ie. exactly those places you now put the pageflag in)?
...
> The idea of the patch is not merely "protecting" those few places, but
> providing a clean, effective generalized method for this purpose. Your
> approach means forcing all developers to remember where they have to
> place this explicit clearing, and introducing unnecessary code
> duplication and an ever growing list of places adding these calls.

I agree with the earlier.  If you know enough to set the flag, then
you know enough to call a function which does a clear before free.
Does seem like a waste of a page flag.

> Also, this let's third-party code (and other kernel interfaces)
> use this feature effortlessly. Moreover, this flag allows easy
> integration with MAC/security frameworks (for instance, SELinux) to mark
> a process as requiring sensitive mappings, in higher level APIs. There are
> plans to work on such a patch, which could be independently proposed
> to the SELinux maintainers.

That sounds like either a thread group flag or a VMA flag, not a page
flag.  If you make it a page flag, you would still need to track it
on the vma or process to handle the event where the page gets migrated
or swapped out.  Really doesn't feel like a page flag is right, but I
reserve the right to be wrong.

Robin