Bug in kernel-2.0.3x or modutils-2.1.x?

B. James Phillippe (bryan@terran.org)
Tue, 19 Jan 1999 12:47:34 -0800 (PST)


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/