[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <33d85206-abfb-86cf-d303-b7efba9cc325@huawei.com>
Date: Fri, 9 Feb 2018 18:41:18 +0200
From: Igor Stoppa <igor.stoppa@...wei.com>
To: Randy Dunlap <rdunlap@...radead.org>, <jglisse@...hat.com>,
<keescook@...omium.org>, <mhocko@...nel.org>, <labbott@...hat.com>,
<hch@...radead.org>, <willy@...radead.org>
CC: <cl@...ux.com>, <linux-security-module@...r.kernel.org>,
<linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>,
<kernel-hardening@...ts.openwall.com>
Subject: Re: [PATCH 6/6] Documentation for Pmalloc
On 04/02/18 23:37, Randy Dunlap wrote:
[...]
>> +reason, could neither be declared as constant, nor it could take advantage
>
> nor could it
ok
[...]
>> +Ex: A policy that is loaded from userspace.
>
> Either
> Example:
> or
> E.g.:
> (meaning For example)
ok
[...]
>> +Different kernel idrivers and threads can use different pools, for finer
>
> drivers
:-( ok
[...]
>> + in use anymore by the requestor, however it will not become avaiable for
>
> requester; however, available
ok
[...]
>> +- pmalloc does not provide locking support wrt allocating vs protecting
>
> Write out "wrt" -> with respect to.
ok
>> + an individual pool, for performance reason. It is recommended to not
>
> reasons. not to
ok & ok
[...]
>> + in the case of using directly vmalloc. The exact number depends on size
>
> of using vmalloc directly. on the size
ok & ok
[...]
>> +6. write protect the pool
>
> write-protect
ok
[...]
>> +7. use in read-only mode the handlers obtained through the allocations
>
> handles ??
yes
---
thanks, igor
Powered by blists - more mailing lists