[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090219190637.GA4846@x200.localdomain>
Date: Thu, 19 Feb 2009 22:06:37 +0300
From: Alexey Dobriyan <adobriyan@...il.com>
To: Ingo Molnar <mingo@...e.hu>
Cc: Dave Hansen <dave@...ux.vnet.ibm.com>,
Nathan Lynch <nathanl@...tin.ibm.com>,
linux-api@...r.kernel.org, containers@...ts.linux-foundation.org,
mpm@...enic.com, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
viro@...iv.linux.org.uk, hpa@...or.com,
Andrew Morton <akpm@...ux-foundation.org>,
torvalds@...ux-foundation.org, tglx@...utronix.de, xemul@...nvz.org
Subject: Banning checkpoint (was: Re: What can OpenVZ do?)
I think that all these efforts to abort checkpoint "intelligently" by
banning it early are completely misguided.
"Checkpointable" property isn't one-way ticket like "tainted" flag,
so doing it like tainted var isn't right, atomic or not, SMP-safe or
not.
With filesystems, one has ->f_op field to compare against banned
filesystems, one more flag isn't necessary.
Inotify isn't supported yet? You do
if (!list_empty(&inode->inotify_watches))
return -E;
without hooking into inotify syscalls.
ptrace(2) isn't supported -- look at struct task_struct::ptraced and
friends.
And so on.
System call (or whatever) does something with some piece of kernel
internals. We look at this "something" when walking data structures and
abort if it's scary enough.
Please, show at least one counter-example.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists