linux-kernel - Re: [RFC][PATCH 00/11] track files for checkpointability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1236368524.10626.96.camel@nimitz>
Date:	Fri, 06 Mar 2009 11:42:04 -0800
From:	Dave Hansen <dave@...ux.vnet.ibm.com>
To:	"Serge E. Hallyn" <serue@...ibm.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	containers <containers@...ts.linux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Alexey Dobriyan <adobriyan@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH 00/11] track files for checkpointability

On Fri, 2009-03-06 at 12:24 -0600, Serge E. Hallyn wrote:
> > But, these "early stage" messages are completely opposed to an approach
> > that uses sys_checkpoint() in some form (like with a -1 fd as an
> > argument).
> 
> Well I disagree with that.  The 'early stage' messages could be seen as
> either:
> 
>         1. a short-term way to prioritize resources to support
>         or
>         2. a long-term way to catch new resources introduced
>         without checkpoint/restart support
> 
> I don't believe 2. would work.  I think 1. would work, but that we
> risk imposing permanent code changes to support a temporary goal.

I should be a bit more clear.  My goal (and I think Ingo's) here is to
come up with a mechanism that will make the checkpoint feature less
likely to break once we merge it into the tree.  I'm looking for a tool
that people can utilize, even if they don't necessarily care about
checkpoint/restart.

If we *completely* depend on sys_checkpoint() as the interface for
determining if we are checkpointable, we don't have such a tool.  We
have a tool that the checkpoint/restart developers and probably some
testers can and certainly will use.  This is still very, very useful.
But, it probably won't ever generate a bug report from anyone who
doesn't specifically care about c/r.

As far as detecting *new* resources.  Well, crap.  I don't think our
little ->may_checkpoint flags can do that.  My little f_op trick will
help and is better than nothing.  But, as you noted, it is far from
perfect because we'll probably have people just copying the generic*
functions into new code.

-- Dave

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