From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Jonathan Corbet <corbet@lwn.net>
Cc: linux-kernel@vger.kernel.org, linux1394-devel@lists.sourceforge.net
Subject: bkl-removal: drivers/firewire and drivers/ieee1394 patches can be reverted/ dropped
Date: Thu, 12 Jun 2008 22:17:49 +0200 (CEST) [thread overview]
Message-ID: <tkrat.08d683698d08913b@s5r6.in-berlin.de> (raw)
Jonathan,
please revert commits
"firewire: cdev lock_kernel() pushdown"
aabbc0e478bf1e82e7f4a9ec61abb8a1a259175b
http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commitdiff;h=aabbc0e478bf1e82e7f4a9ec61abb8a1a259175b
"ieee1394: cdev lock_kernel() pushdown"
8fff9d8cda2b288231fd100333fed26b9bb2042f
http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commitdiff;h=8fff9d8cda2b288231fd100333fed26b9bb2042f
and drop them before mainline submission.
I looked at the respective drivers last month and came to the conclusion
that fw_device_op_open(), dv1394_open(), raw1394_open() are safe to be
called without the BKL held. I specifically looked for possible races
with module initialization or with other processes accessing the
respective character device file interface and found none.
(Well, extremely early openers of dv1394 or raw1394 could find the
devices not yet operational, i.e. they may look to the opener as if no
hardware were present. But this is no real-world problem. All actual
application programs which use those device files will in practice
access them only after module initialization was finished and thus be
able to get through to hardware.)
I found a race condition of video1394_open() with module initialization
and fixed it in commit
"ieee1394: video1394: reorder module init, prepare BKL removal"
6ee70088d975130142debdf1f6fe07958d3d2f26
http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commitdiff;h=6ee70088d975130142debdf1f6fe07958d3d2f26
Thanks,
--
Stefan Richter
-=====-==--- -==- -==--
http://arcgraph.de/sr/
next reply other threads:[~2008-06-12 20:18 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-12 20:17 Stefan Richter [this message]
2008-06-20 20:10 ` Jonathan Corbet
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=tkrat.08d683698d08913b@s5r6.in-berlin.de \
--to=stefanr@s5r6.in-berlin.de \
--cc=corbet@lwn.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux1394-devel@lists.sourceforge.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®