From: Michael Neuhauser <mike@domain.hid>
To: "Adeos-Main@domain.hid" <adeos-main@gna.org>
Subject: [Adeos-main] non-atomic bitop in __adeos_stall_root()
Date: Thu, 27 Jan 2005 21:26:12 +0100 [thread overview]
Message-ID: <1106857570.3241.76.camel@domain.hid> (raw)
Hello!
During my work on Adeos for ARM I've noticed the following: In
__adeos_stall_root() (both 2.4 & 2.6) the stall flag is set like this:
adeos_get_cpu(flags);
__set_bit(IPIPE_STALL_FLAG,&adp_root->cpudata[cpuid].status);
adeos_put_cpu(flags);
I don't understand why the non-atomic __set_bit() is used instead of the
atomic set_bit(). Maybe someone can shed some light on this.
Suppose we have a non-SMP machine. In this case, adeos_get_cpu() is a
nop. Hence, hw-irqs may be enabled when __set_bit() is executed. On ARM,
__set_bit() is implemented as
read from memory; modify register; write to memory
Assume an interrupt happens after the read and before the write and that
some other bit of "status" is modified during the interrupt
=> this modification is lost as the interrupted __set_bit() uses the
value of "status" before the interrupt!
This may not happen on i386 where __set_bit() is implemented as a single
asm instruction (which I assume is interrupt safe). But as
__adeos_stall_root() is contained in include/linux/adeos.h (i.e. generic
code) I think the atomic bitop has to be used.
__adeos_test_and_stall_root() and adeos_unstall_pipeline_from() also use
some non-atomic bitop without ensuring that hw-interrupts are disabled.
Mike
--
Dr. Michael Neuhauser phone: +43 1 789 08 49 - 30
Firmix Software GmbH fax: +43 1 789 08 49 - 55
Vienna/Austria/Europe email: mike@domain.hid
Embedded Linux Development and Services http://www.firmix.at/
next reply other threads:[~2005-01-27 20:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-27 20:26 Michael Neuhauser [this message]
2005-01-27 20:54 ` [Adeos-main] non-atomic bitop in __adeos_stall_root() Philippe Gerum
2005-01-27 21:32 ` Philippe Gerum
2005-01-27 21:00 ` 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=1106857570.3241.76.camel@domain.hid \
--to=mike@domain.hid \
--cc=adeos-main@gna.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.