[PATCH 1/1] cr: fix compilation with CONFIG_UTS_NS=n

[Nathan Lynch]

"Serge E. Hallyn" <serue at us.ibm.com> writes:
> Quoting Nathan Lynch (ntl at pobox.com):
>> Oren Laadan <orenl at cs.columbia.edu> writes:
>> 
>> > I think it's useful to be able to
>> >
>> > 1) checkpoint on a system with !CONFIG_UTS_NS,  and -
>> > 2) checkpoint on a system with CONFIG_UTS_NS and restart on a
>> > system with !CONFIG_UTS_NS (as long as all tasks in the image
>> > share a single uts-ns)
>> 
>> In principle I agree, but what confidence can we have that meaningful
>> testing of such configurations (especially #2) will occur?
>
> History says, low confidence.  So far just 1 is bad enough.  It's
> taking a lot of my time on the LSM c/r (with the various combinations
> of CONFIG_SECURITY, CONFIG_IPC_NS, and CONFIG_CHECKPOINT), and things
> like CONFIG_IPC_NS consistently break c/r anyway.
>
> So for 2 i'm tempted to say let's encode a sha1sum of the .config
> into the checkpoint header.  We'll keep *trying* to support (2), and
> userspace can trivially rewrite the header if it really wants to believe
> we've succeeded.

Are you suggesting having sys_restart code path consult the .config
sha1sum in the image?  Or is it just for the benefit of userspace?  If
the former, I'm having difficulty grasping the benefit.

>
> And for 1, I agree - most distros ship with namespaces enabled
> anyway, and one day I expect we'll get rid of those configs, so
> I see no reason to support CONFIG_CHECKPOINT if any namespaces are
> turned off.
>
> In fact, I thought that last week Dave suggested that, and Nathan
> was against it?  :)

I was against using select in the CHECKPOINT config item to force-enable
CONFIG_*_NS.  Making CHECKPOINT depend on the namespace options strikes
me as a sane tradeoff here.