From: Zhu Yi <yi.zhu@intel.com>
To: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Ivo van Doorn <ivdoorn@gmail.com>,
Adel Gadllah <adel.gadllah@gmail.com>,
linux-wireless@vger.kernel.org, randy.dunlap@oracle.com,
"John W. Linville" <linville@tuxdriver.com>,
fcrespel@gmail.com
Subject: Re: [PATCH] iwlwifi: remove input device and fix rfkill state
Date: Thu, 03 Jul 2008 11:11:11 +0800 [thread overview]
Message-ID: <1215054671.14590.555.camel@debian.sh.intel.com> (raw)
In-Reply-To: <20080703015355.GB20410@khazad-dum.debian.net>
On Wed, 2008-07-02 at 22:53 -0300, Henrique de Moraes Holschuh wrote:
> Hmm, it could cause deadlocks I think. task context takes lock.
> interrupt context tries to run, needs lock, keeps spinning forever
> waiting for it, and if we are not SMP, task context never has a chance
> to release the lock, so we get a deadlock. Is this correct?
Never heard of spin_lock_irqsave()?
> If it is, we better make the atomic path lock-free. Argh. This means
> rfkill->state (the only thing we care about in the atomic path) would
> have to become an atomic variable, and the code changed to cope with
> its value being "volatile", so that it can be used in a lockless
> fashion.
Yup, if protecting rfkill->state is the only intention, a spinlock is
too heavy. set|clear_bit is enough if organizing the state into bitmaps.
BTW, read/write 32-bits aligned on x86 is already atomic.
Thanks,
-yi
next prev parent reply other threads:[~2008-07-03 3:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-01 15:49 [PATCH] iwlwifi: remove input device and fix rfkill state Adel Gadllah
2008-07-01 16:56 ` Henrique de Moraes Holschuh
2008-07-02 8:25 ` Zhu Yi
2008-07-02 15:43 ` Henrique de Moraes Holschuh
2008-07-02 16:00 ` Ivo van Doorn
2008-07-02 18:41 ` Henrique de Moraes Holschuh
2008-07-02 22:31 ` Ivo van Doorn
2008-07-03 1:53 ` Henrique de Moraes Holschuh
2008-07-03 3:11 ` Zhu Yi [this message]
2008-07-03 12:49 ` Henrique de Moraes Holschuh
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=1215054671.14590.555.camel@debian.sh.intel.com \
--to=yi.zhu@intel.com \
--cc=adel.gadllah@gmail.com \
--cc=fcrespel@gmail.com \
--cc=hmh@hmh.eng.br \
--cc=ivdoorn@gmail.com \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=randy.dunlap@oracle.com \
/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.