public inbox for linux-mm@kvack.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Dave Hansen <dave@linux.vnet.ibm.com>
Cc: Oren Laadan <orenl@cs.columbia.edu>,
	Al Viro <viro@ZenIV.linux.org.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	containers@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-api@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	Serge Hallyn <serue@us.ibm.com>, Ingo Molnar <mingo@elte.hu>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [RFC v10][PATCH 08/13] Dump open file descriptors
Date: Mon, 1 Dec 2008 13:02:09 -0800 (PST)	[thread overview]
Message-ID: <alpine.LFD.2.00.0812011258390.3256@nehalem.linux-foundation.org> (raw)
In-Reply-To: <1228164679.2971.91.camel@nimitz>



On Mon, 1 Dec 2008, Dave Hansen wrote:
> 
> Why is this done in two steps?  It first grabs a list of fd numbers
> which needs to be validated, then goes back and turns those into 'struct
> file's which it saves off.  Is there a problem with doing that
> fd->'struct file' conversion under the files->file_lock?

Umm, why do we even worry about this?

Wouldn't it be much better to make sure that all other threads are 
stopped before we snapshot, and if we cannot account for some thread (ie 
there's some elevated count in the fs/files/mm structures that we cannot 
see from the threads we've stopped), just refuse to dump.

There is no sane dump from a multi-threaded app that shares resources 
without that kind of serialization _anyway_, so why even try?

In other words: any races in dumping are fundamental _bugs_ in the dumping 
at a much higher level. There's absolutely no point in trying to make 
something like "dump open fd's" be race-free, because if there are other 
people that are actively accessing the 'files' structure concurrently, you 
had a much more fundamental bug in the first place!

So do things more like the core-dumping does: make sure that all other 
threads are quiescent first!

			Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2008-12-01 21:02 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-27  1:04 [RFC v10][PATCH 00/13] Kernel based checkpoint/restart Oren Laadan
2008-11-27  1:04 ` [RFC v10][PATCH 01/13] Create syscalls: sys_checkpoint, sys_restart Oren Laadan
2008-11-27  1:04 ` [RFC v10][PATCH 02/13] Checkpoint/restart: initial documentation Oren Laadan
2008-11-28 10:45   ` Al Viro
2008-12-01 18:15     ` Dave Hansen
2008-11-27  1:04 ` [RFC v10][PATCH 03/13] General infrastructure for checkpoint restart Oren Laadan
2008-11-27  1:04 ` [RFC v10][PATCH 04/13] x86 support for checkpoint/restart Oren Laadan
2008-11-27  1:04 ` [RFC v10][PATCH 05/13] Dump memory address space Oren Laadan
2008-11-28 10:53   ` Al Viro
2008-12-01 18:00     ` Dave Hansen
2008-12-01 20:57       ` Oren Laadan
2008-11-27  1:04 ` [RFC v10][PATCH 06/13] Restore " Oren Laadan
2008-11-27  1:04 ` [RFC v10][PATCH 07/13] Infrastructure for shared objects Oren Laadan
2008-11-27  1:04 ` [RFC v10][PATCH 08/13] Dump open file descriptors Oren Laadan
2008-11-28 10:19   ` Al Viro
2008-12-01 17:47     ` Dave Hansen
2008-12-01 20:23       ` Oren Laadan
2008-12-01 20:51         ` Dave Hansen
2008-12-01 21:02           ` Linus Torvalds [this message]
2008-12-01 21:25             ` Dave Hansen
2008-12-01 21:20           ` Oren Laadan
2008-11-27  1:04 ` [RFC v10][PATCH 09/13] Restore open file descriprtors Oren Laadan
2008-11-28 11:27   ` Al Viro
2008-12-01 19:22     ` Dave Hansen
2008-12-01 20:41       ` Oren Laadan
2008-12-01 20:54         ` Dave Hansen
2008-12-01 21:00           ` Oren Laadan
2008-12-01 21:07             ` Dave Hansen
2008-12-02  1:31               ` Dave Hansen
2008-12-02  1:12             ` Dave Hansen
2008-11-27  1:04 ` [RFC v10][PATCH 10/13] External checkpoint of a task other than ourself Oren Laadan
2008-11-27  1:04 ` [RFC v10][PATCH 11/13] Track in-kernel when we expect checkpoint/restart to work Oren Laadan
2008-11-27  1:04 ` [RFC v10][PATCH 12/13] Checkpoint multiple processes Oren Laadan
2008-11-27  1:04 ` [RFC v10][PATCH 13/13] Restart " Oren Laadan
2008-12-03 23:58 ` [RFC v10][PATCH 00/13] Kernel based checkpoint/restart Serge E. Hallyn

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=alpine.LFD.2.00.0812011258390.3256@nehalem.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=containers@lists.linux-foundation.org \
    --cc=dave@linux.vnet.ibm.com \
    --cc=hpa@zytor.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@elte.hu \
    --cc=orenl@cs.columbia.edu \
    --cc=serue@us.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=viro@ZenIV.linux.org.uk \
    /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