[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 30 Oct 2018 23:49:12 +0200
From: Igor Stoppa <igor.stoppa@...il.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: Tycho Andersen <tycho@...ho.ws>, Andy Lutomirski <luto@...capital.net>,
Kees Cook <keescook@...omium.org>, Peter Zijlstra <peterz@...radead.org>,
Mimi Zohar <zohar@...ux.vnet.ibm.com>, Dave Chinner <david@...morbit.com>,
James Morris <jmorris@...ei.org>, Michal Hocko <mhocko@...nel.org>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>,
linux-integrity <linux-integrity@...r.kernel.org>,
linux-security-module <linux-security-module@...r.kernel.org>,
Igor Stoppa <igor.stoppa@...wei.com>,
Dave Hansen <dave.hansen@...ux.intel.com>, Jonathan Corbet <corbet@....net>,
Laura Abbott <labbott@...hat.com>, Randy Dunlap <rdunlap@...radead.org>,
Mike Rapoport <rppt@...ux.vnet.ibm.com>,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 10/17] prmem: documentation
On 30/10/2018 23:35, Matthew Wilcox wrote:
> On Tue, Oct 30, 2018 at 10:43:14PM +0200, Igor Stoppa wrote:
>> 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?
The reason to have pools is that, continuing the SELinux example, it
supports reloading the policyDB.
In this case it seems to me that it would be faster to drop the entire
pool in one go, and create a new one when re-initializing the rules.
Or maybe the pool could be flushed, without destroying the metadata.
One more reason for having pools is to assign certain property to the
pool and then rely on it to be applied to every subsequent allocation.
I've also been wondering if pools can be expected to have some well
defined property.
One might be that they do not need to be created on the fly.
The number of pools should be known at compilation time.
At least the meta-data could be static, but I do not know how this would
work with modules.
>>> 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?
And list_add()? or any of the other list related functions?
Don't they end up receiving a similar treatment?
I might have misunderstood your proposal, but it seems to me that they
too will need the same type of pairs rare_modify/rare_protect. No?
And same for hlist, including the _rcu variants.
--
igor
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
