Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 24 Oct 2018 17:30:52 +0300
From: Igor Stoppa <>
To: Randy Dunlap <>,
 Mimi Zohar <>, Kees Cook <>,
 Matthew Wilcox <>, Dave Chinner <>,
 James Morris <>, Michal Hocko <>,,,
Cc:, Dave Hansen <>,
 Jonathan Corbet <>, Laura Abbott <>,
 Mike Rapoport <>,,
Subject: Re: [PATCH 10/17] prmem: documentation


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.



>> +   are attempted after the write protection is in place, will cause
> no comma.



>> +        - Its usefulness depends on the specific use case at hand
> end above sentence with a period, please, like all of the others above it.


>> +    - 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/ ?


>> +  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


>> +  vmalloc for each allocation, but it is undeniably less optimized wrt to
> s/wrt/with respect to/


> Thanks for the documentation.

thanks for the review :-)


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.