Linux Container Development
 help / color / mirror / Atom feed
From: Dan Smith <danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
To: Matt Helsley <matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Cc: containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
Subject: Re: [PATCH] Clear the objhash before completing restart, but delay free until later
Date: Mon, 18 Oct 2010 08:03:13 -0700	[thread overview]
Message-ID: <87eibnr1am.fsf@caffeine.danplanet.com> (raw)
In-Reply-To: <20101017225507.GA10119-52DBMbEzqgQ/wnmkkaCWp/UQ3DHhIser@public.gmane.org> (Matt Helsley's message of "Sun\, 17 Oct 2010 15\:55\:07 -0700")

MH> If we postpone clearing the object hash until restart returns to
MH> userspace there can be a race where the restarted tasks behave
MH> differently due to the references held by the objhash.  One
MH> specific example of this is restarting half-closed pipes.  Without
MH> this patch we've got a race between the coordinator -- about to
MH> clear the object hash -- and two restarted tasks connected via a
MH> half-closed pipe. Because the object hash contains a reference to
MH> both ends of the pipe one end of the pipe will not be closed and
MH> EPIPE/SIGPIPE won't be handled when the reading from the pipe for
MH> instance. As far as the restarted userspace task can tell the pipe
MH> may briefly appear to re-open. Moving the object hash clear
MH> prevents this race and others like it.

MH> Note that eventually the coordinator would close the pipe and
MH> correct behavior would be restored. Thus this bug would only
MH> affect the correctness of userspace -- after a close() the pipe
MH> may briefly re-open and allow more data to be sent before
MH> automatically closing again.

Sure, this sounds fine and I'll be glad to put it into the patch
header.

MH> You might simplify this by making the queue portion into a
MH> separate patch. Then we can discuss that independently of moving
MH> the objhash clear call.

Hmm, I'm not sure what you mean exactly.  The only thing in the patch
other than the queue, is the one-line additional call to _clear().
Without the additional call, the queue is nothing but overhead...

-- 
Dan Smith
IBM Linux Technology Center
email: danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org

      parent reply	other threads:[~2010-10-18 15:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-15 15:20 [PATCH] Clear the objhash before completing restart, but delay free until later Dan Smith
     [not found] ` <1287156039-31496-1-git-send-email-danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2010-10-17 22:55   ` Matt Helsley
     [not found]     ` <20101017225507.GA10119-52DBMbEzqgQ/wnmkkaCWp/UQ3DHhIser@public.gmane.org>
2010-10-18 15:03       ` Dan Smith [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87eibnr1am.fsf@caffeine.danplanet.com \
    --to=danms-r/jw6+rmf7hqt0dzr+alfa@public.gmane.org \
    --cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
    --cc=matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox