public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.

  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