All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: Jan Kiszka <jan.kiszka@domain.hid>
Cc: Xenomai core <Xenomai-core@domain.hid>
Subject: Re: [Xenomai-core] [PATCH 2/2] native: Fix error cleanup of rt_task_create
Date: Mon, 04 Jul 2011 21:29:16 +0200	[thread overview]
Message-ID: <4E12148C.7050500@domain.hid> (raw)
In-Reply-To: <4E0C5EC4.9050900@domain.hid>

On 06/30/2011 01:32 PM, Jan Kiszka wrote:
> On 2011-06-30 13:09, Gilles Chanteperdrix wrote:
>> On 06/30/2011 11:36 AM, Jan Kiszka wrote:
>>> When creating of a shadow task fails, rt_task_create has to free the
>>> task object consistently, not only on registry errors. Then we need to
>>> delete the core thread when fastlock allocation failed. Moreover, fix a
>>> double free of the fastlock object which is now released via the delete
>>> hook. Finally, avoid a use-after-release of the fastlock object in
>>> __task_delete_hook.
>>>
>>> This fixes heap corruptions when running out of resources.
>>>
>>> Signed-off-by: Jan Kiszka <jan.kiszka@domain.hid>
>>> ---
>>> (...)
>>> +
>>> +      fail:
>>> +	if (xnthread_test_state(&task->thread_base, XNSHADOW))
>>> +		xnfree(task);
>>> +
>>> +	return err;
>>>  }
>>>  
>>>  /**
>>
>> Is this needed? I mean, shadows are created in syscall.c, function
>> __rt_task_create, and when rt_task_create returns an error, that
>> function calls rt_task_delete. So, there should be no leak. And worse,
>> here rt_task_delete will use an invalid pointer if we apply that patch.
> 
> The problem is that rt_task_create may both fail early without any
> registration step performed yet and very late when everything (except
> the the registry entry) is already set up. There is no chance for the
> caller __rt_task_create to figure out the precise task registration
> state and properly roll it back. That must be done by rt_task_create.
> 
> This patch ensures that shadow tasks are either successfully registered
> or completely deleted on error. Among other bug scenarios, this avoids
> deleting the task twice, first via xnpod_delete_thread+deletion hook and
> then again via xnfree in the error path of __rt_task_create.

I need to understand completely this issue. But I definitely prefer
seeing the xnfree in the same function as xnmalloc in case of failure.
This makes chasing leaks easier.

-- 
                                                                Gilles.


      reply	other threads:[~2011-07-04 19:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-30  9:36 [Xenomai-core] [PATCH 2/2] native: Fix error cleanup of rt_task_create Jan Kiszka
2011-06-30 11:09 ` Gilles Chanteperdrix
2011-06-30 11:32   ` Jan Kiszka
2011-07-04 19:29     ` Gilles Chanteperdrix [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E12148C.7050500@domain.hid \
    --to=gilles.chanteperdrix@xenomai.org \
    --cc=Xenomai-core@domain.hid \
    --cc=jan.kiszka@domain.hid \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.