From: Rusty Russell <rusty@rustcorp.com.au>
To: "Wang, Stanley" <stanley.wang@intel.com>
Cc: "Zhuang, Louis" <louis.zhuang@intel.com>,
"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>,
Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>
Subject: Re: Kernel module version support.
Date: Fri, 03 Jan 2003 11:00:08 +1100 [thread overview]
Message-ID: <20030103042650.6DDD82C0B1@lists.samba.org> (raw)
In-Reply-To: Your message of "Thu, 02 Jan 2003 22:25:31 +0800." <957BD1C2BF3CD411B6C500A0C944CA2602AFADC0@pdsmsx32.pd.intel.com>
In message <957BD1C2BF3CD411B6C500A0C944CA2602AFADC0@pdsmsx32.pd.intel.com> you
write:
> Hi, Rusty
> I am interested in your module version support implementation. I've read
> your description about it.
Cool. That reminds me.
> 1. How do you plan to store the version information of a kernel module that
> will export some symbols?
> (In the version table of "bzImage"? In a specified section in this kernel
> module? In other place? Or don't
> store?)
Currently I don't do this. I discussed solutions briefly with Kai
some time ago, but I'll have to revisit it. Getting the core kernel
symbols versioned covers 90% of the problem though, and shows the
validity of the approach.
> 2. You mentioned that "modules which want to export symbols place
> their full path name in the .needmodversion section. Just before the
> kernel is linked, these names are extracted, and genksyms scans
> those files to create a version table. This table is then linked
> into the kernel". And I think we must recalculate all version
> informaiton every time when we re built the kernel in this way. Why
> don't we place all the module version information in some files just
> like old days.
That's a build system detail: it can use that list to generate the
versions on demand of course.
> 3. You mentioned that "these symbol versions are then checked on
> insmod". I wanna whether it means you would like to restore the
> "/proc/ksyms" file or QUERY_MODULE SYSCALL to export the kernel
> version table to the user space application.
The language is a little loose. The kernel does the actual checking:
#ifdef CONFIG_MODVERSIONING
static inline int check_version(const char *name,
const char *symname,
const struct modversion_info *versions,
unsigned int num)
{
unsigned int i, k;
/* First search kernel (unversioned symbols not listed). */
for (k = 0; !streq(modversions[k].symbol, symname); k++)
if (!modversions[k].symbol[0])
return 0;
/* Now see if module has matching symbol. */
for (i = 0; i < num; i++) {
if (streq(versions[i].symbol, symname)) {
if (versions[i].checksum == modversions[k].checksum)
return 0;
printk("%s: disagrees about version of symbol %s\n",
name, symname);
DEBUGP("Kernel checksum %lX vs module %lX\n",
modversions[k].checksum, versions[i].checksum);
return -ESRCH;
}
}
/* Not in module's version table. OK, but that taints the kernel. */
printk("%s: no version for %s found: kernel tainted.\n",
name, symname);
tainted |= TAINT_FORCED_MODULE;
return 0;
}
Hope that clarifies,
Rusty.
PS. I'll update the patch soon, I promise...
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
next prev parent reply other threads:[~2003-01-03 4:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-02 14:25 Kernel module version support Wang, Stanley
2003-01-03 0:00 ` Rusty Russell [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-01-03 5:36 Wang, Stanley
2003-01-03 5:54 ` Rusty Russell
[not found] <957BD1C2BF3CD411B6C500A0C944CA2601F11711@pdsmsx32.pd.intel.com>
2003-01-03 8:14 ` Rusty Russell
[not found] <957BD1C2BF3CD411B6C500A0C944CA2601F11712@pdsmsx32.pd.intel.com>
2003-01-04 5:06 ` Rusty Russell
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=20030103042650.6DDD82C0B1@lists.samba.org \
--to=rusty@rustcorp.com.au \
--cc=kai@tp1.ruhr-uni-bochum.de \
--cc=linux-kernel@vger.kernel.org \
--cc=louis.zhuang@intel.com \
--cc=stanley.wang@intel.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