From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: kernel-janitors@lists.osdl.org, kjhall@us.ibm.com, akpm@osdl.org,
maxk@qualcomm.com, linux-kernel@vger.kernel.org
Subject: Re: [KJ][PATCH] Correct misc_register return code handling in several drivers
Date: Wed, 25 Oct 2006 08:42:42 +1000 [thread overview]
Message-ID: <1161729762.10524.660.camel@localhost.localdomain> (raw)
In-Reply-To: <20061024125306.GA1608@hmsreliant.homelinux.net>
On Tue, 2006-10-24 at 08:53 -0400, Neil Horman wrote:
> On Tue, Oct 24, 2006 at 01:34:34PM +1000, Benjamin Herrenschmidt wrote:
> > On Mon, 2006-10-23 at 13:19 -0400, Neil Horman wrote:
> > > Hey All-
> > > Janitor patch to clean up return code handling and exit from failed
> > > calls to misc_register accross several modules.
> >
> > The patch doesn't match the description... What are those INIT_LIST_HEAD
> > things ? Is this something I've missed or is this a new requirement for
> > all misc devices ? Can't it be statically initialized instead ?
> >
>
> The INIT_LIST_HEAD is there to prevent a potential oops on module removal.
> misc_register, if it fails, leaves miscdevice.list unchanged. That means its
> next and prev pointers contain NULL or garbage, when both pointers should contain
> &miscdevice.list. If we don't do that, then there is a chance we will oops on
> module removal when we do a list_del in misc_deregister on the moudule_exit
> routine. I could have done this statically, but I thought it looked cleaner to
> do it with the macro in the code.
Hrm... I see, but I still for some reason don't like it that much.. I'd
rather have misc_register() do the initialisation unconditionally before
it can fail, don't you think ?
We would theorically have a similar problem with any driver that does
xxxx_register(&static_struct)
and
xxxx_unregister(&static_struct)
(pci, usb, etc...)
As long as there are list heads involved. I think the proper solution
here is to have either the unregister be smart and test for NULL/NULL or
the register initialize those fields before it has a chance to fail.
Ben.
next prev parent reply other threads:[~2006-10-24 22:43 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-23 17:19 [KJ][PATCH] Correct misc_register return code handling in several drivers Neil Horman
2006-10-23 17:39 ` Alan Cox
2006-10-23 17:54 ` Neil Horman
2006-10-23 18:23 ` Kylene Jo Hall
2006-10-23 19:18 ` Alan Cox
2006-10-23 18:01 ` [KJ] [PATCH] " Dan Carpenter
2006-10-23 18:13 ` Neil Horman
2006-10-23 18:32 ` Dan Carpenter
2006-10-23 18:44 ` Neil Horman
2006-10-24 3:34 ` [KJ][PATCH] " Benjamin Herrenschmidt
2006-10-24 12:53 ` Neil Horman
2006-10-24 13:24 ` [KJ] [PATCH] " Matthew Wilcox
2006-10-24 15:07 ` Neil Horman
2006-10-24 22:42 ` Benjamin Herrenschmidt [this message]
2006-10-25 13:17 ` [KJ][PATCH] " Neil Horman
2006-11-01 13:56 ` Neil Horman
2006-11-01 23:55 ` Andrew Morton
2006-11-02 14:21 ` Neil Horman
2006-11-02 0:05 ` Jesper Juhl
2006-11-02 0:11 ` Randy Dunlap
2006-11-02 0:24 ` Jesper Juhl
2006-11-02 0:27 ` Andrew Morton
2006-11-02 0:44 ` Jesper Juhl
2006-11-02 1:12 ` Randy Dunlap
2006-11-02 1:23 ` Jesper Juhl
2006-11-02 1:22 ` Randy Dunlap
2006-11-15 0:04 ` Randy Dunlap
2006-11-15 9:05 ` Jesper Juhl
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=1161729762.10524.660.camel@localhost.localdomain \
--to=benh@kernel.crashing.org \
--cc=akpm@osdl.org \
--cc=kernel-janitors@lists.osdl.org \
--cc=kjhall@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maxk@qualcomm.com \
--cc=nhorman@tuxdriver.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