Thread (140 messages) 140 messages, 21 authors, 2018-12-04

Re: [PATCH 10/17] prmem: documentation

From: Matthew Wilcox <willy@infradead.org>
Date: 2018-10-30 21:36:06
Also in: linux-doc, linux-security-module, lkml

On Tue, Oct 30, 2018 at 10:43:14PM +0200, Igor Stoppa wrote:
On 30/10/2018 21:20, Matthew Wilcox wrote:
quoted
quoted
quoted
So the API might look something like this:

	void *p = rare_alloc(...);	/* writable pointer */
	p->a = x;
	q = rare_protect(p);		/* read-only pointer */
With pools and memory allocated from vmap_areas, I was able to say

protect(pool)

and that would do a swipe on all the pages currently in use.
In the SELinux policyDB, for example, one doesn't really want to
individually protect each allocation.

The loading phase happens usually at boot, when the system can be assumed to
be sane (one might even preload a bare-bone set of rules from initramfs and
then replace it later on, with the full blown set).

There is no need to process each of these tens of thousands allocations and
initialization as write-rare.

Would it be possible to do the same here?
What Andy is proposing effectively puts all rare allocations into
one pool.  Although I suppose it could be generalised to multiple pools
... one mm_struct per pool.  Andy, what do you think to doing that?
quoted
but we'd probably wrap it in list_for_each_rare_entry(), just to be nicer.
This seems suspiciously close to the duplication of kernel interfaces that I
was roasted for :-)
Can you not see the difference between adding one syntactic sugar function
and duplicating the entire infrastructure?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help