linux-kernel - Re: [RFC][PATCH 3/5] check 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: <1235435430.26788.212.camel@nimitz>
Date:	Mon, 23 Feb 2009 16:30:30 -0800
From:	Dave Hansen <dave@...ux.vnet.ibm.com>
To:	"Serge E. Hallyn" <serue@...ibm.com>
Cc:	Alexey Dobriyan <adobriyan@...il.com>, Ingo Molnar <mingo@...e.hu>,
	containers <containers@...ts.linux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC][PATCH 3/5] check files for checkpointability

On Mon, 2009-02-23 at 17:49 -0600, Serge E. Hallyn wrote:
> Quoting Dave Hansen (dave@...ux.vnet.ibm.com): 
> > Introduce a files_struct counter to indicate whether a particular
> > file_struct has ever contained a file which can not be
> > checkpointed.  This flag is a one-way trip; once it is set, it may
> > not be unset.
> > 
> > We assume at allocation that a new files_struct is clean and may
> > be checkpointed.  However, as soon as it has had its files filled
> > from its parent's, we check it for real in __scan_files_for_cr().
> > At that point, we mark it if it contained any uncheckpointable
> > files.
> > 
> > We also check each 'struct file' when it is installed in a fd
> > slot.  This way, if anyone open()s or managed to dup() an
> > unsuppored file, we can catch it.
> 
> So what is the point of tagging the files_struct counter and
> making it a one-way trip?  Why not just check every file at
> checkpoint time?

We need both.

This allows us to tell where and when we went wrong.  Take a process
that's been running for a month.  After 5 days it did something random
to keep it from being checkpointed.  You're going to have forgotten all
about it 25 days later.  This gives us an opportunity to spit into dmesg
or just plain log it.  It also gives the app some ability to reflect and
see what its uncheckpointable attributes are.  

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