Hi Helmut...
We moved the creation of the socket outside of the match() function into the init() area of the module. And the warning for that vanished as was to be expected. Thanks for the help there.
OK, one problem was solved....
But the warning that appears everytime kernel_sendmsg() is invoked still remains.
Hm.... honestly I have no good idea about it. It could be a blocking function too, possibly because of page allocation (non atomic..)
Therefore we tried to move the transmission of the ICMP echo requests into an iptables target module, hoping that this will change context of the call, but it did not. Unfortunately, this is the only solution to sending ICMP echo requests from inside the kernel that we came up with. We still can't manage to alter an existing UDP sk_buff for use in icmp_send(skbuff, ICMP_ECHO, 0, 0), it always segfaults.
Just a raw idea....what if you move the ICMP delivery part completely out from iptables context...shall we say..into separate kernel threads? What do you think? Is it doable?
What problems are to be expected if we deploy with the existing sleep bug (the module seems to keep running fine)?
CMIIW, I believe by far you only tested it on UML kernel, right? Well, in UML, I think it won't bring too much trouble since basically UML is just simulating the atomic context when in reality it is still an interruptible context... but... in real machine and real kernel (non UML), IMHO it could bring problem, possibly kernel panic. But to see if my theory is correct, please try your program/patch inside qemu. Since qemu simulate a complete x86 system, you can 99% accurately predict what will happen in real iron.
Is this only important for SMP and multicore systems (which the system we deploy on might not necessarily be)?
I don't think so. Even in UP, atomic is still atomic ..of course there is a good reason why a section is marked as atomic. Mostly, it is because of the need to avoid race condition (e.g competing with another invocation of another interrupt handler). regards, Mulyadi -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
