Re: Re: sleeping function called from invalid context in slab.c and sock.c (long,code,stacktrace)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux