mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Werner Almesberger <wa@almesberger.net>
To: Michael Nguyen <mnguyen@ariodata.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: RE2: [OKS] Module removal
Date: Mon, 1 Jul 2002 22:40:34 -0300	[thread overview]
Message-ID: <20020701224034.C2295@almesberger.net> (raw)
In-Reply-To: <8A098FDFC6EED94B872CA2033711F86F0EC115@orion.ariodata.com>; from mnguyen@ariodata.com on Mon, Jul 01, 2002 at 01:21:57PM -0700

Michael Nguyen wrote:
> I saw this mail flashes thru the reflector. It is worrying to know
> that this great feature is on the discussion table for removal.

One work-around that was suggested was to allow modules to be
superseded, i.e. the old module stays forever, but a new
version can be loaded in parallel. I must say that I'm very
sceptic about this idea, as it seems likely to just mask more
severe problems.

If I remember right, the main arguments why module removal can
race with references were:

 - buggy modules that don't even know themselves if they still
   serve a purpose or not (solution: fix 'em)
 - likewise, but with the excuse that correctness was
   sacrificed on the altar of performance
 - references getting copied without the module knowing. Looks
   like a problem in the subsystem managing the references.
   (This was discussed mainly in the context of automating
   reference tracking.)
 - removal happening immediately after module usage count is
   decremented to zero may unload module before module has
   executed "return" instruction

While I can accept the theoretical possibility that some code
may indeed not be able to afford handling the module usage
count, I kind of doubt that such conditions exist in real life.

For the removal-before-return problem, I thought a bit about it
on my return flight. It would seem to me that an "atomic"
"decrement_module_count_and_return" function would do the trick.

That function would prepare to return from its caller, then
decrement the module count, and finally do the return. That way,
no resources of the caller would be used after the module usage
counter drops to zero. Obviously, any related cleanup would have
to happen before this. Also, you couldn't call
decrement_module_count_and_return from a function that gets
called from another function in the same module.

Not sure if such a solution for removal-before-return has been
considered/rejected yet. It would seem obvious enough.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://icapeople.epfl.ch/almesber/_____________________________________/

  reply	other threads:[~2002-07-02  1:33 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-01 20:21 Michael Nguyen
2002-07-02  1:40 ` Werner Almesberger [this message]
2002-07-02  2:25   ` Keith Owens
2002-07-02  3:11     ` Werner Almesberger
2002-07-02  3:42       ` Keith Owens
2002-07-02  4:11         ` Werner Almesberger
2002-07-02 22:23         ` Alexander Viro
2002-07-09 19:23         ` Russ Lewis
2002-07-02  4:08     ` Brian Gerst
2002-07-02  4:53       ` Keith Owens
2002-07-02  5:43         ` Werner Almesberger
2002-07-02 16:36           ` Werner Almesberger
2002-07-02 16:50             ` Benjamin Herrenschmidt
2002-07-02 18:05               ` Werner Almesberger
2002-07-03  3:50               ` Pavel Machek
2002-07-04  4:11             ` Bill Davidsen
2002-07-04  6:29               ` Werner Almesberger
2002-07-04  6:50                 ` Werner Almesberger
2002-07-07 21:09                   ` Jamie Lokier
2002-07-07 21:41                     ` Oliver Neukum
2002-07-08  0:31                       ` Jamie Lokier
2002-07-08  6:42                         ` Oliver Neukum
2002-07-08  0:18                     ` Bill Davidsen
2002-07-08  0:46                       ` Jamie Lokier
2002-07-08  6:22                         ` Daniel Phillips
2002-07-08 10:16                           ` Bill Davidsen
2002-07-09  0:07                         ` Werner Almesberger
2002-07-09  0:27                           ` Keith Owens
2002-07-09  3:09                             ` Werner Almesberger
2002-07-09  6:25                             ` Roman Zippel
2002-07-09  8:59                               ` Kai Germaschewski
2002-07-09 11:06                                 ` Roman Zippel
2002-07-04 12:29                 ` Bill Davidsen
2002-07-09  1:50                 ` Kevin O'Connor
2002-07-09  2:37                   ` Werner Almesberger
2002-07-02 23:35         ` Alexander Viro
2002-07-02 22:41       ` RE2: " Alexander Viro
2002-07-02  8:52     ` Helge Hafting
2002-07-02 16:22       ` Werner Almesberger

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=20020701224034.C2295@almesberger.net \
    --to=wa@almesberger.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mnguyen@ariodata.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

all inboxes | Powered by JetHome®