[CRIU] regression with 8ffbe754bd9: rst: Lock rst memory allocations earlier

[Tycho Andersen]

On Wed, Jul 15, 2015 at 05:33:19PM +0300, Pavel Emelyanov wrote:
> On 07/15/2015 03:42 PM, Tycho Andersen wrote:
> > Hi Pavel,
> > 
> > I'm seeing a regression with the patch in the subject, it does this
> > for a while:
> > 
> > (00.138425)    492: Error (rst-malloc.c:130): BUG at rst-malloc.c:130
> > 
> > And then eventually seg faults. Any ideas?
> 
> Well, yes :) I (unintentionally) broke this with the patch you've spotted.
> Sorry about that :(
> 
> The thing is that this code
> 
>         if (lsm) {
>                 char *rendered;
>                 int ret;
> 
>                 ret = render_lsm_profile(lsm, &rendered);
>                 xfree(lsm);
>                 if (ret < 0) {
>                         goto err_nv;
>                 }
> 
>                 lsm_pos = rst_mem_cpos(RM_PRIVATE);
>                 lsm_profile_len = strlen(rendered);
>                 lsm = rst_mem_alloc(lsm_profile_len + 1, RM_PRIVATE);
>                 if (!lsm) {
>                         xfree(rendered);
>                         goto err_nv;
>                 }
> 
>                 strncpy(lsm, rendered, lsm_profile_len);
>                 xfree(rendered);
> 
>         }
> 
> form sigreturn_restore() extends the remapable area _after_ we've found
> a hole for it in the restorer address spaces. So we're risking in having
> some memory overwritten by it.
> 
> I missed this "if (lsm) ..." code when I was disabling allocations from 
> remapable area (with rst_mem_alloc) after the hole is found. The fix for 
> that is to move all the rst_mem_alloc() calls _before_ rst_mem_lock(), 
> but I don't have LSM-enabled system to check the fix works. Can you do
> it, please? :)

Yep, I can send a patch.

Tycho