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