From: Ben Hutchings <ben@decadent.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@suse.de>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org,
Linux-Arch <linux-arch@vger.kernel.org>,
Thorsten Glaser <tg@mirbsd.de>,
Debian kernel team <debian-kernel@lists.debian.org>,
linux-m68k@vger.kernel.org, debian-68k@lists.debian.org
Subject: Re: [PATCH 1/2] topology: Check for missing CPU devices
Date: Mon, 09 Jan 2012 02:56:56 +0000 [thread overview]
Message-ID: <1326077816.4097.8.camel@deadeye> (raw)
In-Reply-To: <1326077272.4097.3.camel@deadeye>
[-- Attachment #1: Type: text/plain, Size: 1424 bytes --]
On Mon, 2012-01-09 at 02:47 +0000, Ben Hutchings wrote:
> On Sun, 2012-01-08 at 16:18 -0800, Linus Torvalds wrote:
> > Ok, both of the patches look sane to me, but it would really be nice
> > to hear from somebody with the actual affected architectures, and get
> > a tested-by.
> >
> > Testing it on hacked-up x86 sounds fine, but doesn't quite have the
> > same kind of "yes, this fixes the actual problem" feel to it.
>
> Indeed.
>
> > Also, can you clarify: does the second patch make the first patch just
> > an "irrelevant safety net", or are there possible callers of
> > topology_add_dev() that could cause problems? I'm just wondering
> > whether maybe the safety net ends up then possibly hiding some future
> > bug where we (once more) don't register a cpu and then never really
> > notice?
> [...]
>
> driver_init() doesn't check that cpu_dev_init() - or any of the other
> functions it calls - is successful. So in theory at least we could boot
> and still have no CPU devices after the first patch.
I mean to say that we could have no CPU devices after the *second*
patch. So the first patch is an extra defence against that. (Though we
could just as well panic if register_cpu() fails at boot time.)
Ben.
--
Ben Hutchings
Life is what happens to you while you're busy making other plans.
- John Lennon
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2012-01-09 2:56 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-08 20:48 [PATCH 1/2] topology: Check for missing CPU devices Ben Hutchings
2012-01-08 20:55 ` [PATCH 2/2] cpu: Register a generic CPU device on architectures that currently do not Ben Hutchings
2012-01-09 20:14 ` Geert Uytterhoeven
2012-01-09 0:18 ` [PATCH 1/2] topology: Check for missing CPU devices Linus Torvalds
2012-01-09 1:06 ` richard -rw- weinberger
2012-01-09 1:29 ` Linus Torvalds
2012-01-09 2:52 ` Ben Hutchings
2012-01-09 14:19 ` Richard Weinberger
2012-01-09 20:15 ` Geert Uytterhoeven
2012-01-09 2:47 ` Ben Hutchings
2012-01-09 2:56 ` Ben Hutchings [this message]
2012-01-09 20:23 ` Linus Torvalds
2012-01-09 20:13 ` Geert Uytterhoeven
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=1326077816.4097.8.camel@deadeye \
--to=ben@decadent.org.uk \
--cc=akpm@linux-foundation.org \
--cc=debian-68k@lists.debian.org \
--cc=debian-kernel@lists.debian.org \
--cc=geert@linux-m68k.org \
--cc=gregkh@suse.de \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@vger.kernel.org \
--cc=tg@mirbsd.de \
--cc=torvalds@linux-foundation.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.