All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philippe Gerum <rpm@xenomai.org>
To: Dmitry Adamushko <dmitry.adamushko@domain.hid>
Cc: xenomai@xenomai.org, Jan Kiszka <jan.kiszka@domain.hid>
Subject: Re: [Xenomai-help] -110 error on rt_task_send... bug?
Date: Sun, 13 Aug 2006 22:24:11 +0200	[thread overview]
Message-ID: <1155500652.4298.15.camel@domain.hid> (raw)
In-Reply-To: <1155480473.11108.22.camel@domain.hid>

On Sun, 2006-08-13 at 16:47 +0200, Philippe Gerum wrote:
> On Sat, 2006-08-12 at 23:14 +0200, Philippe Gerum wrote:
> 
> > IOW, a construct like "if (synch-> ...." when returning from suspension
> > is the root of all evil. We must not depend on anything requiring such
> > dereference when resuming the thread. A way to fix this would be to
> > introduce a new thread status flag which gets raised whenever some
> > object ownership is stolen, so that we would not have to inspect the
> > synch object anymore to know about such situation, and rely on
> > potentially wrong information from the ->owner field. We would only have
> > to inspect the status flags of the thread that got "robbed" (i.e. the
> > one that resumes) and act accordingly. I will post a patch implementing
> > this, after I have solved all the related issues.
> 
> The patch below provides a more general fix to the issues introduced by
> the resource stealing feature. There is still one case where this code
> could attempt to reuse a stolen resource unsafely,

More precisely, a stolen then deleted resource, and those events must
happen while the caller of xnsynch_sleep_on has been readied from
suspension, but not yet switched in. Deletion is the issue there,
meaning that the resource might be destroyed immediately after it has
been released, without any attempt to synchronize with the next consumer
of such resource.

-- 
Philippe.




      reply	other threads:[~2006-08-13 20:24 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-08  1:50 [Xenomai-help] -110 error on rt_task_send... bug? Vincent Levesque
2006-08-08 22:12 ` Jan Kiszka
2006-08-09  9:35   ` Dmitry Adamushko
2006-08-09 11:42     ` [Xenomai-core] " Dmitry Adamushko
2006-08-09 15:09       ` Ulrich Schwab
2006-08-09 15:42         ` Dmitry Adamushko
2006-08-10 18:14           ` Vincent Levesque
2006-08-10 18:18             ` Dmitry Adamushko
2006-08-10  8:25         ` Jan Kiszka
2006-08-10 10:11           ` Dmitry Adamushko
2006-08-10 22:13     ` Philippe Gerum
2006-08-11  7:50       ` Dmitry Adamushko
2006-08-12 10:33       ` Dmitry Adamushko
2006-08-12 21:14         ` Philippe Gerum
2006-08-13 14:47           ` Philippe Gerum
2006-08-13 20:24             ` Philippe Gerum [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=1155500652.4298.15.camel@domain.hid \
    --to=rpm@xenomai.org \
    --cc=dmitry.adamushko@domain.hid \
    --cc=jan.kiszka@domain.hid \
    --cc=xenomai@xenomai.org \
    /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.