LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Adrian Bunk <bunk@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Alexey Dobriyan <adobriyan@gmail.com>
Subject: Re: [PATCH 2/2] modules: Whine about suspicious return values from module's ->init() hook
Date: Thu, 6 Mar 2008 11:32:54 +1100	[thread overview]
Message-ID: <200803061132.54554.rusty@rustcorp.com.au> (raw)
In-Reply-To: <20080305230445.GB937@cs181133002.pp.htv.fi>

On Thursday 06 March 2008 10:04:45 Adrian Bunk wrote:
> 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@gmail.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.

Unfortunately not: it's a semantic change.  Previously as per Unix standard, 
>=0 was good, < 0 was bad.  This resulted in some confusion, and so Alexey 
proposed tightening the rules, to only allow <= 0 values.

So we don't know that the module is buggy.  It's possible that it's returning 
ENODEV instead of -ENODEV, but it's also possible that it's returning 1 to 
mean "ok".

> And not loading the module also seems to be a good compromise between
> making the user notice the problem and not doing a panic().

Depends which way the failure is.  Andrew said not to break existing systems.

To avoid this, we'd need an audit which noone wants to do, so we're being 
lazy.

Hope that clarifies my thinking,
Rusty.

      reply	other threads:[~2008-03-06  0:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-04 12:21 [PATCH 1/2] modules: Fix module waiting for dependent modules' init Rusty Russell
2008-03-04 12:22 ` [PATCH 2/2] modules: Whine about suspicious return values from module's ->init() hook Rusty Russell
2008-03-05 23:04   ` Adrian Bunk
2008-03-06  0:32     ` Rusty Russell [this message]

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=200803061132.54554.rusty@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=adobriyan@gmail.com \
    --cc=bunk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: [PATCH 2/2] modules: Whine about suspicious return values from module'\''s ->init() hook' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).