lkml.org 
[lkml]   [2018]   [Oct]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 10/17] prmem: documentation
    On Wed, Oct 31, 2018 at 10:36:59AM +0100, Peter Zijlstra wrote:
    > On Tue, Oct 30, 2018 at 10:58:14AM -0700, Matthew Wilcox wrote:
    > > On Tue, Oct 30, 2018 at 10:06:51AM -0700, Andy Lutomirski wrote:
    > > > > On Oct 30, 2018, at 9:37 AM, Kees Cook <keescook@chromium.org> wrote:
    > > > I support the addition of a rare-write mechanism to the upstream kernel.
    > > > And I think that there is only one sane way to implement it: using an
    > > > mm_struct. That mm_struct, just like any sane mm_struct, should only
    > > > differ from init_mm in that it has extra mappings in the *user* region.
    > >
    > > I'd like to understand this approach a little better. In a syscall path,
    > > we run with the user task's mm. What you're proposing is that when we
    > > want to modify rare data, we switch to rare_mm which contains a
    > > writable mapping to all the kernel data which is rare-write.
    > >
    > > So the API might look something like this:
    > >
    > > void *p = rare_alloc(...); /* writable pointer */
    > > p->a = x;
    > > q = rare_protect(p); /* read-only pointer */
    > >
    > > To subsequently modify q,
    > >
    > > p = rare_modify(q);
    > > q->a = y;
    > > rare_protect(p);
    >
    > Why would you have rare_alloc() imply rare_modify() ? Would you have the
    > allocator meta data inside the rare section?

    Normally when I allocate some memory I need to initialise it before
    doing anything else with it ;-)

    I mean, you could do:

    ro = rare_alloc(..);
    rare = rare_modify(ro);
    rare->a = x;
    rare_protect(rare);

    but that's more typing.

    \
     
     \ /
      Last update: 2018-10-31 12:33    [W:4.451 / U:0.512 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site