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]
Date:	Fri, 11 Jul 2008 04:32:58 +0400
From:	Alexey Dobriyan <adobriyan@...il.com>
To:	Dave Hansen <dave@...ux.vnet.ibm.com>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"Serge E. Hallyn" <serue@...ibm.com>,
	Oren Laadan <orenl@...columbia.edu>,
	Kirill Korotaev <dev@...allels.com>,
	containers@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, Nadia.Derbey@...l.net,
	Andrew Morton <akpm@...ux-foundation.org>, nick@...k-andrew.net
Subject: Re: Checkpoint/restart (was Re: [PATCH 0/4] - v2 - Object creation
	with a specified id)

On Thu, Jul 10, 2008 at 12:47:32PM -0700, Dave Hansen wrote:
> On Thu, 2008-07-10 at 12:21 -0700, Eric W. Biederman wrote:
> > > Are we talking about the VMA itself, or the memory backing the VMA?
> > 
> > The memory backing the VMA.  We need to store the page protections
> > that the memory was mapped with as well now that you point it out.  A
> > VMA is not user space visible, which is why we can arbitrarily split
> > and merge VMAs.
> 
> It is visible with /proc/$pid/{maps,smaps,numamaps?}.  That's the only
> efficient way I know of from userspace to figure out where userspace's
> memory is and if it *is* file backed, and what the permissions are.

None of those files exist if PROC_FS is off.

> We also can't truly split them arbitrarily because the memory cost of
> the VMAs themselves might become too heavy (the remap_file_pages()
> problem).
> 
> It gets trickier when things are also private mappings in addition to
> being in a file-backed VMA.  We *do* need to checkpoint those, but only
> the pages to which there was a write.
> 
> There's also the problem of restoring things read-only, but VM_MAYWRITE.
> If there's a high level of (non-COW'd) sharing of these anonymous areas,
> we may not be able to even restore the set of processes unless we can
> replicate the sharing.  We might run out of memory if the sharing isn't
> replicated.

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