All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@domain.hid>
To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Cc: adeos-main <adeos-main@gna.org>, Philippe Gerum <rpm@xenomai.org>
Subject: Re: [Adeos-main] Unchecked ipipe_test_pipeline_from
Date: Mon, 09 Nov 2009 19:25:49 +0100	[thread overview]
Message-ID: <4AF85EAD.5020408@domain.hid> (raw)
In-Reply-To: <4AF85B75.40408@domain.hid>

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Hi Philippe,
>>
>> just noticed: The __ipipe_check_percpu_access of __ipipe_get_cpu_var,
>> added in 2.6.29, makes ipipe_test_pipeline_from unusable for debugging
>> purposes. It now triggers a false positive warning if the caller did not
>> disabled interrupts or stalled its pipeline. One such user under Xenomai
>> is rthal_local_irq_disabled, and that is used to check RTDM driver
>> handlers /wrt leaking IRQ masks.
> 
> It does not look like a false positive. If the task issuing the call to
> rthal_local_irq_disabled function was migrated at the wrong time, it
> could check the stall flag on the wrong cpu.

Unless you want to test the migration logic itself, a plain task in
whatever domain should never see a CPU-depend rthal_local_irq_disabled -
migration should never alter the context in this respect.

> So, it looks like
> rthal_local_irq_disabled should be fixed to turn off irqs during the check.
> 

Would work, but would also be more heavy-weighted then needed.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux


  reply	other threads:[~2009-11-09 18:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-09 18:07 [Adeos-main] Unchecked ipipe_test_pipeline_from Jan Kiszka
2009-11-09 18:12 ` Gilles Chanteperdrix
2009-11-09 18:25   ` Jan Kiszka [this message]
2009-11-09 18:40     ` Gilles Chanteperdrix
2009-11-09 18:50       ` Jan Kiszka
2009-11-09 23:01         ` Philippe Gerum
2009-11-09 23:10           ` Jan Kiszka
2009-11-10 10:27             ` Philippe Gerum

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=4AF85EAD.5020408@domain.hid \
    --to=jan.kiszka@domain.hid \
    --cc=adeos-main@gna.org \
    --cc=gilles.chanteperdrix@xenomai.org \
    --cc=rpm@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.