Mailing List Archive

Bug in kernel-2.0.3x or modutils-2.1.x?
Hello,
This is a copy of a message I sent to Richard Henderson regarding
what I think might be a bug in the linux-2.0.3x kernel or modutils-2.1.x.
I have not received a response from Richard yet, but I'm wondering if
anyone else can comment on whether or not they think this is a kernel bug.
I've added new comments in []'s below.
thanks,
-bp
--
B. James Phillippe . bryan@terran.org
Linux Engineer/Admin . http://www.terran.org/~bryan
Member since 1.1.59 . finger:bryan@earth.terran.org
---------- Forwarded message ----------
Subject: Possible bug in modutils-2.1.121
Date: Mon, 18 Jan 1999 16:38:39 -0800 (PST)
From: B. James Phillippe <bryan@terran.org>
To: rth@tamu.edu
Hello,
I am trying to hunt down a very annoying (and subtle!) problem I am having
loading a module on 2.0.3x with modutils-2.1.121. First question, which
might obviate any further questions: should modutils-2.1.121 be a good and
viable modutils package version to use with version 2.0.x kernels?
Now, the problem. I have a module (a driver for Rainbow Technologies'
crypto-swift protocol accelerator) which will Oops the kernel at insmod
time under rare circumstances. I have determined this:
With modutils version 2.0.0, the module (call it "pacc.o") reports a
codesize of 50260 and npages of 13. The module loads and works as
expected. With modutils version 2.1.121 [or 2.1.85; the RH-5.2 version],
the identical module in the identical kernel reports a codesize of 8192 and
npages of 3. The module Oopses on memcpy_fromfs copying the last word of
the code to mp->addr. This is line 169 of kernel/module.c in 2.0.33:
memcpy_fromfs((char *)mp->addr + sizeof (long), code, codesize);
HOWEVER, if I add even a single printk() to the module pacc.o and recompile
it, to make it's codesize 8212, say, then the module loads without incident
with modutils-2.1.121. I have not seen a difference in npages between
these two versions for other modules. So it seems there is either:
a.) a problem with insmod mis-reporting the proper size/pages of a module
under some conditions. I'm suspicious of the fact that only my particular
module seems to have it's codesize change depending on the modutils
version, but otherwise...
b.) a bug in the kernel loading modules whose size is a multiple of
PAGE_SIZE (sounds possible). I almost suspect this because if I hardcode
the memcpy_fromfs to be 1 longword less, it loads okay. [.This is the one I
suspect; the algorithm that determines how many pages looks incorrect to
me; currently it is:
npages = (size + sizeof (long) + PAGE_SIZE - 1) / PAGE_SIZE;
but I think this would be better:
npages = ((size + sizeof (long)) / PAGE_SIZE) + 1;
although it would still waste a page for cases where size % PAGE_SIZE == 0.
Comments?]
c.) a bug in the pacc.o module that for some reason makes it incompatible
with newer modutils. Easy to point the finger here, but I'm not sure if
it's even possible(?)
Can you offer any advice?
thanks,
-bp
--
B. James Phillippe . bryan@terran.org
Linux Engineer/Admin . http://www.terran.org/~bryan
Member since 1.1.59 . finger:bryan@earth.terran.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/