[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <42e65f5f-2753-54a7-08a4-b51e56dfedbe@gmail.com>
Date: Wed, 24 Oct 2018 17:30:52 +0300
From: Igor Stoppa <igor.stoppa@...il.com>
To: Randy Dunlap <rdunlap@...radead.org>,
Mimi Zohar <zohar@...ux.vnet.ibm.com>, Kees Cook <keescook@...omium.org>,
Matthew Wilcox <willy@...radead.org>, Dave Chinner <david@...morbit.com>,
James Morris <jmorris@...ei.org>, Michal Hocko <mhocko@...nel.org>,
kernel-hardening@...ts.openwall.com, linux-integrity@...r.kernel.org,
linux-security-module@...r.kernel.org
Cc: igor.stoppa@...wei.com, Dave Hansen <dave.hansen@...ux.intel.com>,
Jonathan Corbet <corbet@....net>, Laura Abbott <labbott@...hat.com>,
Mike Rapoport <rppt@...ux.vnet.ibm.com>, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 10/17] prmem: documentation
Hi,
On 24/10/18 06:48, Randy Dunlap wrote:
> Hi,
>
> On 10/23/18 2:34 PM, Igor Stoppa wrote:
[...]
>> +- The present document doesn't address such transient.
>
> transience.
ok
[...]
>> + are attempted after the write protection is in place, will cause
>
> no comma.
ok
[...]
>> + - Its usefulness depends on the specific use case at hand
>
> end above sentence with a period, please, like all of the others above it.
ok
>> + - The "START_WR" mode is the only one which provides immediate protection, at the cost of speed.
>
> Please try to keep the line above and a few below to < 80 characters in length.
> (because some of us read rst files as text files, with a text editor, and line
> wrap is ugly)
ok, I still have to master .rst :-(
[...]
>> +- The users of rare write must take care of ensuring the atomicity of the
>
> s/rare write/write rare/ ?
thanks
>> + action, respect to the way they use the data being altered; for example,
>
> This .. "respect to the way" is awkward, but I don't know what to
> change it to.
>
>> + take a lock before making a copy of the value to modify (if it's
>> + relevant), then alter it, issue the call to rare write and finally
>> + release the lock. Some special scenario might be exempt from the need
>> + for locking, but in general rare-write must be treated as an operation
>
> It seemed to me that "write-rare" (or write rare) was the going name, but now
> it's being called "rare write" (or rare-write). Just be consistent, please.
write-rare it is, because it can be shortened as wr_xxx
rare_write becomes rw_xxx
which wrongly hints at read/write, which it definitely is not
>> + tlb entries. It still does a better job of it, compared to invoking
>
> TLB
ok
>> + vmalloc for each allocation, but it is undeniably less optimized wrt to
>
> s/wrt/with respect to/
yes
> Thanks for the documentation.
thanks for the review :-)
--
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.
