From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
To: Jamie Lokier <jamie@shareable.org>
Cc: Oren Laadan <orenl@cs.columbia.edu>,
Matt Helsley <matthltc@us.ibm.com>,
serue@us.ibm.com,
Containers <containers@lists.linux-foundation.org>,
linux-fsdevel@vger.kernel.org
Subject: Re: [RFC][PATCH 1/4][cr]: Add uid, euid params to f_modown()
Date: Wed, 12 May 2010 10:30:48 -0700 [thread overview]
Message-ID: <20100512173048.GC11144@us.ibm.com> (raw)
In-Reply-To: <20100512170513.GD19314@shareable.org>
Jamie Lokier [jamie@shareable.org] wrote:
| Sukadev Bhattiprolu wrote:
| > Checkpoint/restart of file-owner.
| >
| > Add uid, euid parameters to f_modown(). These parameters will be needed
| > when restarting an application (and hence restoring the file information),
| > from a checkpoint image.
|
| This is used to make sure I/O signals on sockets, ttys, devices and so
| on are delivered to a particular process.
Good point.
|
| If any of those signals are lost when an event happens around the same
Well, signals are not lost across C/R - if they were pending at
checkpoint, they will be pending on restart.
| time as c/r (for example, more data arriving on a pipe, a device
| becomes readable/writable, or room becoming available to write, or
| urgent data on a socket), a process depending on it can get stuck -
| unless the process knows that c/r happened, so it knows to call
| select() on all those fds after the c/r.
Real devices like ttys are still TBD from C/R perspective - so data
arriving from the tty is still a problem. Applications using such
devices cannot be checkpointed.
But for pipes, (and sockets ?) we expect that both ends are checkpointed
as a container. So before the container is frozen for checkpoint, either
both the write() and SIGIO (due to new data on the pipe) both happen or
neither.
Sukadev
next prev parent reply other threads:[~2010-05-12 17:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-11 22:38 [RFC][PATCH 0/4][cr]: Checkpoint/restart file-owner info Sukadev Bhattiprolu
2010-05-11 22:38 ` [RFC][PATCH 1/4][cr]: Add uid, euid params to f_modown() Sukadev Bhattiprolu
2010-05-12 17:05 ` Jamie Lokier
2010-05-12 17:30 ` Sukadev Bhattiprolu [this message]
2010-05-12 20:12 ` Oren Laadan
2010-05-11 22:38 ` [RFC][PATCH 2/4][cr]: Define __f_setown_uid() Sukadev Bhattiprolu
2010-05-12 14:07 ` Matthew Wilcox
2010-05-12 17:05 ` Sukadev Bhattiprolu
2010-05-11 22:38 ` [RFC][PATCH 3/4][cr]: Checkpoint file-owner information Sukadev Bhattiprolu
2010-05-11 22:38 ` [RFC][PATCH 4/4][cr]: Restore file_owner info Sukadev Bhattiprolu
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=20100512173048.GC11144@us.ibm.com \
--to=sukadev@linux.vnet.ibm.com \
--cc=containers@lists.linux-foundation.org \
--cc=jamie@shareable.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=matthltc@us.ibm.com \
--cc=orenl@cs.columbia.edu \
--cc=serue@us.ibm.com \
/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;
as well as URLs for NNTP newsgroup(s).