From: Roman Zippel <zippel@linux-m68k.org>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Jeff Garzik <jgarzik@pobox.com>,
linux-kernel@vger.kernel.org, akpm@digeo.com
Subject: Re: [PATCH] fixup loop blkdev, add module_get
Date: Mon, 13 Jan 2003 23:20:44 +0100 [thread overview]
Message-ID: <3E233BBC.CB78BB67@linux-m68k.org> (raw)
In-Reply-To: 20030113040906.A72D22C052@lists.samba.org
Hi,
Rusty Russell wrote:
> > 1) we do not prevent root from shooting themselves in the foot,
>
> I don't understand this point.
Something to remember here: When we kill processes with SIGKILL, do we
risk kernel stability? E.g. do we turn TASK_UNINTERRUPTIBLE into
TASK_INTERRUPTIBLE, do we allow to kill init or do we leave resources
behind?
> > 3) and this kind of code just adds error handling for no reason, when
> > _not_ handling the error keeps the code more clean.
>
> No, the reason is simple: the admin has said they want the damn module
> removed. They've *told* you what they want. Why do you want to
> disobey them? 8)
How do you want to make this mechanism halfway safe to use? Did you
check that all modules can still be deconfigured after you put them into
the going state via the wait option?
Both the wait and the force option are extremely dangerous options. You
are trying to implement something behind the modules back, what can only
go wrong as soon as the module becomes slightly more complex. If you
want to force the removal of a module, you should least attempt to keep
it safe and this is not possible without the help of the module. A
global don't-use switch is a worse idea than the global module count, if
it's forced onto the modules.
I'm really curious when we get the first bug reports from people, who
"only" unloaded a module. :(
bye, Roman
prev parent reply other threads:[~2003-01-13 22:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-12 3:56 [PATCH] fixup loop blkdev, add module_get Jeff Garzik
2003-01-13 0:55 ` Rusty Russell
2003-01-13 2:03 ` Jeff Garzik
2003-01-13 4:08 ` Rusty Russell
2003-01-13 22:20 ` Roman Zippel [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=3E233BBC.CB78BB67@linux-m68k.org \
--to=zippel@linux-m68k.org \
--cc=akpm@digeo.com \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
/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