Skip to contentSkip to conversation

Another idea for simplifying locking in kernel/module.c

DISCUSSION Adam J. Richter 4 participants 5 messages Jan 10, 2003 – Jan 11, 2003

lore
Share & tools
lore
#0 lore raw
Quoted 7 lines · Rusty Russell

In message <[email protected]> you write:

Quoted 4 lines

Here is a way to replace all of the specialized "stop CPU"
locking code in kernel/module.c with an rw_semaphore by using down_read_trylock in try_module_get() and down_write when beginning to unload the module.

And now you can't modularize netfilter modules.

Why not? Last time you went looking in the networking code
for an example of something that had to increment a module reference in a context where blocking was not allowed you ended up conceding that you example was incorrect. If you've now found an example, please let me know.

I just booted my gateway machine to a kernel using my
aforemetioned patch and various netfilter modules. I've surfed the web, FTP'ed file and run irc through it. It seems to be okay. Here is the lsmod listing from it.

Module                  Size  Used by
iptable_nat            28324  1 [unsafe],
ip_conntrack           39788  2 iptable_nat,[unsafe],
ext2                   60712  0 -
pcmcia_core            55744  0 -
i810                   65816  0 -
atkbd                   6820  0 -
i8042                   8864  0 -
serio                   4564  2 atkbd,i8042,
autofs                 14992  1 -
ipt_TCPMSS              3568  1 [unsafe],
iptable_filter          2272  1 [unsafe],
ip_tables              17296  8 iptable_nat,ipt_TCPMSS,iptable_filter,[unsafe],
nfsd                  111824  1 [unsafe],
exportfs                6160  1 nfsd,
nfs                   132092  0 -
lockd                  58736  3 nfsd,nfs,[unsafe],
sunrpc                114136  4 nfsd,nfs,lockd,[unsafe],
pppoe                  14336  1 [unsafe],
pppox                   3480  1 pppoe,
af_packet              20760  2 [unsafe],
ppp_async              11296  0 -
ppp_generic            30264  5 pppoe,pppox,ppp_async,
slhc                    6576  1 ppp_generic,
ipv4                  392804  88 iptable_nat,ip_conntrack,sunrpc,af_packet,[unsafe],
unix                   23884  11 [unsafe],
sis_agp                 4224  0 -
agpgart                23248  2 sis_agp,
ohci_hcd               28400  0 -
usbcore               101108  3 ohci_hcd,
ac97_codec             12432  0 -
sis900                 16548  0 -
tulip                  52960  2 [unsafe],
crc32                   4272  2 sis900,tulip,
ext3                  112232  3 -
jbd                    65840  1 ext3,
mbcache                 7764  2 ext2,ext3,
ide_disk               17332  5 -
ide_mod               143684  1 ide_disk,[unsafe],
Adam J. Richter     __     ______________   575 Oroville Road
[email protected]     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America

"Free Software For The Rest Of Us."

#1 lore raw

I'll bite .... what the flip is [unsafe] ??

Quoted 64 lines · Adam J. Richter
Quoted 7 lines · Rusty Russell

In message <[email protected]> you write:

Quoted 4 lines

Here is a way to replace all of the specialized "stop CPU"
locking code in kernel/module.c with an rw_semaphore by using down_read_trylock in try_module_get() and down_write when beginning to unload the module.

And now you can't modularize netfilter modules.

Why not? Last time you went looking in the networking code
for an example of something that had to increment a module reference in a context where blocking was not allowed you ended up conceding that you example was incorrect. If you've now found an example, please let me know.

I just booted my gateway machine to a kernel using my
aforemetioned patch and various netfilter modules. I've surfed the web, FTP'ed file and run irc through it. It seems to be okay. Here is the lsmod listing from it.

Module                  Size  Used by
iptable_nat            28324  1 [unsafe],
ip_conntrack           39788  2 iptable_nat,[unsafe],
ext2                   60712  0 -
pcmcia_core            55744  0 -
i810                   65816  0 -
atkbd                   6820  0 -
i8042                   8864  0 -
serio                   4564  2 atkbd,i8042,
autofs                 14992  1 -
ipt_TCPMSS              3568  1 [unsafe],
iptable_filter          2272  1 [unsafe],
ip_tables              17296  8 iptable_nat,ipt_TCPMSS,iptable_filter,[unsafe],
nfsd                  111824  1 [unsafe],
exportfs                6160  1 nfsd,
nfs                   132092  0 -
lockd                  58736  3 nfsd,nfs,[unsafe],
sunrpc                114136  4 nfsd,nfs,lockd,[unsafe],
pppoe                  14336  1 [unsafe],
pppox                   3480  1 pppoe,
af_packet              20760  2 [unsafe],
ppp_async              11296  0 -
ppp_generic            30264  5 pppoe,pppox,ppp_async,
slhc                    6576  1 ppp_generic,
ipv4                  392804  88 iptable_nat,ip_conntrack,sunrpc,af_packet,[unsafe],
unix                   23884  11 [unsafe],
sis_agp                 4224  0 -
agpgart                23248  2 sis_agp,
ohci_hcd               28400  0 -
usbcore               101108  3 ohci_hcd,
ac97_codec             12432  0 -
sis900                 16548  0 -
tulip                  52960  2 [unsafe],
crc32                   4272  2 sis900,tulip,
ext3                  112232  3 -
jbd                    65840  1 ext3,
mbcache                 7764  2 ext2,ext3,
ide_disk               17332  5 -
ide_mod               143684  1 ide_disk,[unsafe],
Adam J. Richter     __     ______________   575 Oroville Road
[email protected]     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
Quoted 7 lines

"Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Andre Hedrick
LAD Storage Consulting Group

#2 lore raw

In message <[email protected]> you
write:

Quoted 2 lines

I'll bite .... what the flip is [unsafe] ??

Use of obsolete (racy) module reference count interface. ie. someone's upping the reference count with __MOD_INC_USE_COUNT() or MOD_INC_USE_COUNT(), not "try_module_get()", so we can't tell them that the module is going away so they couldn't get a reference.

Going through and fixing these up is generally fairly easy.

Hope that clarifies,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

#3 lore raw
In reply to Andre Hedrick
Quoted 2 lines · Andre Hedrick

I'll bite .... what the flip is [unsafe] ??

Actually, I believe it means the modules doesn't use try_module_get instead of the old I_cant_remember_the_name macro.

Signature · 3 lines
bill davidsen <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
#4 lore raw
In reply to Adam J. Richter

In message <[email protected]> you write:

Quoted 7 lines
Quoted 5 lines · Rusty Russell

In message <[email protected]> you write:

Quoted 4 lines

Here is a way to replace all of the specialized "stop CPU"
locking code in kernel/module.c with an rw_semaphore by using down_read_trylock in try_module_get() and down_write when beginning to unload the module.

Quoted 6 lines
Quoted 1 line

And now you can't modularize netfilter modules.

Why not? Last time you went looking in the networking code
for an example of something that had to increment a module reference in a context where blocking was not allowed you ended up conceding that you example was incorrect.

No, you're thinking of the IPv4 stack. I didn't use netfilter as an example, because that opens me to "well, FIX NETFILTER then!". If it were the only case, it's probably arguable.

The problems with netfilter modules are exactly why I started looking at module locking over two years ago.

Quoted 3 lines

I just booted my gateway machine to a kernel using my
aforemetioned patch and various netfilter modules. I've surfed the web, FTP'ed file and run irc through it. It seems to be okay.

Sure! That's because the netfilter modules use a horrific hack, by keeping their own "usage" counts and then spinning (potentially forever) on unload until it hits zero.

Logically the skb->nfct would have an owner field in it.

Now, performance. You want a brlock, at least: the performance of either the security infrastructure or netfilter modules is going to suck horribly with anything else. And the bogolock used in module.c is even lighter weight than a brlock, with its associated atomic ops.

Hope that clarifies...
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.