[CRIU] [PATCH] compel: compel_emergency_sigframe() helper introduced

Dmitry Safonov 0x7f454c46 at gmail.com
Mon Mar 27 08:13:18 PDT 2017


2017-03-27 17:25 GMT+03:00 Stanislav Kinsburskiy <skinsbursky at virtuozzo.com>:
>
>
> 27.03.2017 16:07, Dmitry Safonov пишет:
>>
>> Yes, but fini_sigreturn() at this moment is called only for parasite-based
>> infection. While the patch exports API for non-parasite case of infection.
>> So, as I've asked before, can we complement it with usage of the formed
>> sigframe in the case of non-parasite infection?
>> It may be just a helper that has inside compel_syscall() with
>> rt_sigreturn.
>> I mean, if anyone is going to use API for forming sigframe, he will
>> have to write such helper. Maybe it's better to provide one for integrity?
>>
>
> It's not that simple.
> User has to provide address *within* process address space, where sigframe
> must be placed, *to* sigframe creation routine.
> IOW, one need:
> 1) Some service mapping within process (doesn't exist in non-parasite case
> of infection), which he can use to store sigframe
> 2) Some way to call sigreturn from *within* the process (doesn't exist in
> non-parasite case of infection)
> 3) Calling to "rt_sigreturn" needs this sigframe address.
>
> Thus, from my POW, libcompel can to provide this helper "as is".
> Or this facility has to be significantly improved by hiding all this remote
> mapping creation, sigrame construction and rt_sigreturn call to some kind of
> helpers like below:
>
> int compel_put_some_straw(struct parasite_ctl *ctl);
>
> and paired (static, inlined, whatever else to prevent linking with
> libcompel):
>
> int compel_fall_from_the tree(void);
>

Well, I would vote for something like:

compel_remote_mmap(struct parasite_ctl *ctl, unsigned long addr)
/* actually renamed compel_unmap() */
compel_remote_unmap(struct parasite_ctl *ctl, unsigned long addr)
compel_sigframe_prepare(struct rt_sigframe *raddr,
   user_regs_struct_t *regs, k_rtsigset_t* sig)
compel_sigframe_sigreturn(struct rt_sigframe *raddr)

Maybe the naming could be improved.
This way we would have complete API for preparing sigframes for any
register set, blocked signals mask and for sigreturning to constructed
frames. All without parasite's help.

Otherwise the original patch exports API for preparing sigframe only
at the point where an application was stopped and leaves reader's
exercise what to do with this sigframe afterward.

What do you think, is it convenient API for your project?
I don't insist, but that looks logical to me avoiding inchoate APIs.

-- 
             Dmitry



More information about the CRIU mailing list