[lkml]   [2009]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subjectcheckpoint/restart: taking refcounts on kernel objects
    On Tue, 2009-04-14 at 21:04 +0400, Alexey Dobriyan wrote:
    > > Right while I have opinions on some things in this list, I didn't
    > > mean to imply positions on these items. My question was: are
    > > there are differences you want to call out?
    > Sorry? "none needed" is relevant to only item 3. If tasks don't
    > dissapear during checkpoint, why would netns dissapear.
    > Taking refcount on checkpoint(2) is likely unneeded.
    > But it's low-level detail anyway.

    I guess it is a matter of whether we consider a task that gets unfrozen
    a kernel bug or not. If we don't take refcounts and we do reference an
    object that disappears, then we *certainly* have a kernel bug that can
    crash the kernel. If we take refcounts, we at least limit the ways in
    which the kernel can crash when something screwy happens.

    On the other hand, the objhash is a kinda weird way to do it. Taking
    and releasing arbitrary refcounts on arbitrary kernel objects one level
    too much of abstraction for me.

    Come to think of it... In the pipe case, we're *guaranteed* to have
    someone hold an extra refcount for us after we encounter the first side
    of the pipe: the other side of the pipe. If the other side isn't there,
    then we didn't need to save the reference. If it is there, it was
    holding a refcount and we didn't need an extra one.

    -- Dave

     \ /
      Last update: 2009-04-14 19:27    [W:0.023 / U:48.292 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site