From: Frederic Weisbecker <fweisbec@gmail.com>
To: John Kacur <jkacur@redhat.com>
Cc: tglx@linutronix.de, Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org, linux-rt-users@vger.kernel.org,
Clark Williams <williams@redhat.com>
Subject: Re: [PATCH RFC] BKL not necessary in cpuid_open
Date: Wed, 7 Oct 2009 21:12:58 +0200 [thread overview]
Message-ID: <20091007191255.GD5903@nowhere> (raw)
In-Reply-To: <alpine.LFD.2.00.0910072016190.15183@localhost.localdomain>
On Wed, Oct 07, 2009 at 08:19:32PM +0200, John Kacur wrote:
>
> I've been staring at the BKL lock in cpuid_open, and I can't see what it
> is protecting. However, I may have missed something - even something
> obvious, so comments are welcome.
>
> From 25c0f07b3ec5533c0e690e06198baa4300ee4a8c Mon Sep 17 00:00:00 2001
> From: John Kacur <jkacur@redhat.com>
> Date: Wed, 7 Oct 2009 20:06:12 +0200
> Subject: [PATCH] The BKL is not necessary in cpuid_open
> Most of the variables are local to the function. It IS possible that for
> struct cpuinfo_x86 *c
> c could point to the same area. However, this is used read only.
>
> Signed-off-by: John Kacur <jkacur@redhat.com>
> ---
> arch/x86/kernel/cpuid.c | 3 ---
> 1 files changed, 0 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/kernel/cpuid.c b/arch/x86/kernel/cpuid.c
> index 6a52d4b..8bb8401 100644
> --- a/arch/x86/kernel/cpuid.c
> +++ b/arch/x86/kernel/cpuid.c
> @@ -118,8 +118,6 @@ static int cpuid_open(struct inode *inode, struct file *file)
> struct cpuinfo_x86 *c;
> int ret = 0;
>
> - lock_kernel();
> -
> cpu = iminor(file->f_path.dentry->d_inode);
> if (cpu >= nr_cpu_ids || !cpu_online(cpu)) {
> ret = -ENXIO; /* No such CPU */
> @@ -129,7 +127,6 @@ static int cpuid_open(struct inode *inode, struct file *file)
> if (c->cpuid_level < 0)
> ret = -EIO; /* CPUID not supported */
> out:
> - unlock_kernel();
> return ret;
> }
Everything look safe there.
Looking at what happens if the targeted cpu is removed:
I don't know if device_destroy() waits for the last reader to
complete on the given device file, but if it does, it's really
safe, if not:
- The cpu_data(cpu) won't be released anyway, only some values inside
c will be changed, wich is not that a big issue, and the bkl
doesn't help about that either
- We just checked if the cpu is online. It can be put offline
just after. Whatever the bkl or not, it can also be put offline
between open and read calls.
So I think this bkl doesn't protect anything.
Reviewed-by: Frederic Weisbecker <fweisbec@gmail.com>
PS: We have the exact same pattern in arch/x86/kernel/msr.c:msr_open()
next prev parent reply other threads:[~2009-10-07 19:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-07 18:19 [PATCH RFC] BKL not necessary in cpuid_open John Kacur
2009-10-07 19:12 ` Frederic Weisbecker [this message]
2009-10-07 19:14 ` Sven-Thorsten Dietrich
2009-10-07 19:31 ` John Kacur
2009-10-07 20:00 ` Sven-Thorsten Dietrich
2009-10-07 19:43 ` [PATCH] x86: Remove the bkl from msr_open() Frederic Weisbecker
2009-10-07 20:15 ` John Kacur
2009-10-07 21:10 ` [tip:x86/cpu] x86, msr: " tip-bot for Frederic Weisbecker
2009-10-07 20:13 ` [PATCH RFC] BKL not necessary in cpuid_open Frederic Weisbecker
2009-10-07 21:01 ` Thomas Gleixner
2009-10-07 21:44 ` Frederic Weisbecker
2009-10-07 21:58 ` John Kacur
2009-10-10 21:18 ` Frederic Weisbecker
2009-10-07 22:43 ` [tip:x86/cpu] x86, cpuid: Remove the bkl from cpuid_open() tip-bot for John Kacur
2009-10-09 16:05 ` [PATCH RFC] BKL not necessary in cpuid_open Arnd Bergmann
[not found] <1033457751.1452271255124941735.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com>
2009-10-09 21:55 ` John Kacur
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=20091007191255.GD5903@nowhere \
--to=fweisbec@gmail.com \
--cc=jkacur@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=williams@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox