All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Olaf Hering <olaf@aepfle.de>
Cc: kexec@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] add hook to read_from_oldmem() to check for non-ram pages
Date: Fri, 6 May 2011 12:30:19 -0700	[thread overview]
Message-ID: <20110506123019.80461d5d.akpm@linux-foundation.org> (raw)
In-Reply-To: <20110506105545.GA16945@aepfle.de>

On Fri, 6 May 2011 12:55:46 +0200
Olaf Hering <olaf@aepfle.de> wrote:

> Should the called code increase/decrease the modules refcount instead?
> I remember there was some MODULE_INC/MODULE_DEC macro (cant remember the
> exact name) at some point. What needs to be done inside the module to
> prevent an unload while its still in use? Is it __module_get/module_put
> for each call of fn()? 

A try_module_get(THIS_MODULE) in the register function will do the trick.
However it's unneeded.  Documentation/DocBook/kernel-hacking.tmpl tells us

try_module_get() module_put()

    These manipulate the module usage count, to protect against
    removal (a module also can't be removed if another module uses one
    of its exported symbols: see below).  Before calling into module
    code, you should call <function>try_module_get()</function> on
    that module: if it fails, then the module is being removed and you
    should act as if it wasn't there.  Otherwise, you can safely enter
    the module, and call <function>module_put()</function> when you're
    finished.

So as your module will have a reference to vmcore.c's register and unregister
functions, nothing needs to be done: the presence of the client module alone
will pin the vmcore.c module.

However it's all moot, because the fs/proc/vmcore.c code cannot
presently be built as a module and it's rather unlikely that it ever
will be.


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Olaf Hering <olaf@aepfle.de>
Cc: linux-kernel@vger.kernel.org, kexec@lists.infradead.org
Subject: Re: [PATCH] add hook to read_from_oldmem() to check for non-ram pages
Date: Fri, 6 May 2011 12:30:19 -0700	[thread overview]
Message-ID: <20110506123019.80461d5d.akpm@linux-foundation.org> (raw)
In-Reply-To: <20110506105545.GA16945@aepfle.de>

On Fri, 6 May 2011 12:55:46 +0200
Olaf Hering <olaf@aepfle.de> wrote:

> Should the called code increase/decrease the modules refcount instead?
> I remember there was some MODULE_INC/MODULE_DEC macro (cant remember the
> exact name) at some point. What needs to be done inside the module to
> prevent an unload while its still in use? Is it __module_get/module_put
> for each call of fn()? 

A try_module_get(THIS_MODULE) in the register function will do the trick.
However it's unneeded.  Documentation/DocBook/kernel-hacking.tmpl tells us

try_module_get() module_put()

    These manipulate the module usage count, to protect against
    removal (a module also can't be removed if another module uses one
    of its exported symbols: see below).  Before calling into module
    code, you should call <function>try_module_get()</function> on
    that module: if it fails, then the module is being removed and you
    should act as if it wasn't there.  Otherwise, you can safely enter
    the module, and call <function>module_put()</function> when you're
    finished.

So as your module will have a reference to vmcore.c's register and unregister
functions, nothing needs to be done: the presence of the client module alone
will pin the vmcore.c module.

However it's all moot, because the fs/proc/vmcore.c code cannot
presently be built as a module and it's rather unlikely that it ever
will be.


  reply	other threads:[~2011-05-06 19:30 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-07  9:56 dynamic oldmem in kdump kernel Olaf Hering
2011-04-07  9:56 ` Olaf Hering
2011-04-07 10:23 ` Américo Wang
2011-04-07 10:23   ` Américo Wang
2011-04-07 13:12   ` Olaf Hering
2011-04-07 13:12     ` Olaf Hering
2011-04-08 10:49     ` Américo Wang
2011-04-08 10:49       ` Américo Wang
2011-05-02 10:22 ` Olaf Hering
2011-05-02 10:22   ` Olaf Hering
2011-05-03 19:08 ` [PATCH] add hook to read_from_oldmem() to check for non-ram pages Olaf Hering
2011-05-03 19:08   ` Olaf Hering
2011-05-05 21:25   ` Andrew Morton
2011-05-05 21:25     ` Andrew Morton
2011-05-06 10:55     ` Olaf Hering
2011-05-06 10:55       ` Olaf Hering
2011-05-06 19:30       ` Andrew Morton [this message]
2011-05-06 19:30         ` Andrew Morton
2011-05-06 19:39         ` Olaf Hering
2011-05-06 19:39           ` Olaf Hering
2011-05-06 19:55           ` Andrew Morton
2011-05-06 19:55             ` Andrew Morton
2011-05-06 13:20   ` [PATCH v2] " Olaf Hering
2011-05-06 13:20     ` Olaf Hering

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=20110506123019.80461d5d.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olaf@aepfle.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.