[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080305230445.GB937@cs181133002.pp.htv.fi>
Date: Thu, 6 Mar 2008 01:04:45 +0200
From: Adrian Bunk <bunk@...nel.org>
To: Rusty Russell <rusty@...tcorp.com.au>
Cc: LKML <linux-kernel@...r.kernel.org>,
Alexey Dobriyan <adobriyan@...il.com>
Subject: Re: [PATCH 2/2] modules: Whine about suspicious return values from
module's ->init() hook
On Tue, Mar 04, 2008 at 11:22:26PM +1100, Rusty Russell wrote:
> Subject: Whine about suspicious return values from module's ->init() hook
> Date: Mon, 11 Feb 2008 01:09:06 +0300
> From: Alexey Dobriyan <adobriyan@...il.com>
>
> Return value convention of module's init functions is 0/-E. Sometimes, e.g.
> during forward-porting mistakes happen and buggy module created, where result
> of comparison "workqueue != NULL" is propagated all the way up to
> sys_init_module. What happens is that some other module created workqueue in
> question, our module created it again and module was successfully loaded.
>
> Or it could be some other bug.
>
> Let's make such mistakes much more visible. In retrospective, such messages
> would noticeably shorten some of my head-scratching sessions.
>
> Note, that dump_stack() is just a way to get attention from user.
> Sample message:
>
> sys_init_module: 'foo'->init suspiciously returned 1, it should follow 0/-E convention
> sys_init_module: loading module anyway...
>...
While I agree with Andrew that a BUG() would not be appropriate here I'm
wondering why the module should be loaded?
We do know that something in the module is buggy.
And not loading the module also seems to be a good compromise between
making the user notice the problem and not doing a panic().
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists