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:50:21 +0100 [thread overview]
Message-ID: <4AF8646D.1000204@domain.hid> (raw)
In-Reply-To: <4AF86204.6000700@domain.hid>
Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> 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.
>
> If it is debug stuff, does the heavy-weight matter that much?
>
Actually, I'm no longer sure that a preemption check for
ipipe_stall_pipeline_from makes sense at all. Am I missing some case?
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2009-11-09 18:50 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
2009-11-09 18:40 ` Gilles Chanteperdrix
2009-11-09 18:50 ` Jan Kiszka [this message]
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=4AF8646D.1000204@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.