Re: [PATCH 8/8] checkpoint/restart of SysV SHM_HUGETLB regions

[Nathan Lynch <ntl-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>]

On Thu, 2010-09-16 at 20:40 -0400, Oren Laadan wrote:
> 
> On 09/14/2010 04:02 PM, Nathan Lynch wrote:
> > Large page-backed shm regions require special handling, especially
> > during restart.  The association of a large page with a shm region's
> > inode can occur only in the context of a process causing a fault with
> > the region mapped into its mm.  In order to restore that association,
> > temporarily shmat-attach the restored SHM_HUGETLB region to the
> > restarting process's mm, using the just-restored ipc namespace
> > instead of the current one (the nsproxy switch hasn't occured yet).
> > 
> > Since the temporary shmat of the region during restart causes some of
> > the shm attributes to be updated, re-restore them from the ipc_shm
> > checkpoint header after unmapping.
> 
> Would it work to just move the original call to load_ipc_shm_hdr()
> further down in restore_ipc_shm(), especially since the mutex is
> not needed anymore - that way you don't need to re-restore them ?

load_ipc_shm_hdr indirectly calls the security context restore stuff, so
I'm not sure whether it's okay to change the ordering here.  But perhaps
it would make sense to defer restoring the shm_* fields until after
restoring contents.

Of course, it would be best if we could figure out a way to restore
SHM_HUGETLB contents without artificially attaching segments to the
restoring task's mm.  But so far I haven't been able to do that.