It's running on 3.0.13. For certain reason, we have to run it on some "older" version of kernel. Regards, Jerry On Sat, Mar 7, 2015 at 4:42 AM, Neil Horman <nhorman@xxxxxxxxxxxxx> wrote: > On Fri, Mar 06, 2015 at 06:44:54PM -0800, Jerry Jerry wrote: >> Hi Neil, >> >> Now we ran into another issue with sendmsg(). The call to sendmsg() >> returns without error, but we found system messages in >> /var/log/messages, which seem memory allocation issues. Is this a bug, >> or this is the way it has to be? If the latter, what do you suggest to >> catch or avoid this kind kernel error? Since the system call to >> sendmsg() doesn't return such error, our application cannot catch it >> and this causes problem (the data actually are not sent out by >> kernel). >> > Hmm, what kernel version are you running? I don't see this in the latest source > tree. > > Neil > >> 7474 Mar 6 00:20:59 linux83 kernel: [ 8853.073003] The following is >> only an harmless informational message. >> 7475 Mar 6 00:20:59 linux83 kernel: [ 8853.073009] Unless you get a >> _continuous_flood_ of these messages it means >> 7476 Mar 6 00:20:59 linux83 kernel: [ 8853.073011] everything is >> working fine. Allocations from irqs cannot be >> 7477 Mar 6 00:20:59 linux83 kernel: [ 8853.073012] perfectly reliable >> and the kernel is designed to handle that. >> 7478 Mar 6 00:20:59 linux83 kernel: [ 8853.073018] testapp: page >> allocation failure: order:7, mode:0x20 >> 7479 Mar 6 00:20:59 linux83 kernel: [ 8853.073025] Pid: 30025, comm: >> testapp Not tainted 3.0.13-0.27-default #1 >> 7480 Mar 6 00:20:59 linux83 kernel: [ 8853.073030] Call Trace: >> 7481 Mar 6 00:20:59 linux83 kernel: [ 8853.073085] >> [<ffffffff810048b5>] dump_trace+0x75/0x300 >> 7482 Mar 6 00:20:59 linux83 kernel: [ 8853.073101] >> [<ffffffff8143ea0f>] dump_stack+0x69/0x6f >> 7483 Mar 6 00:20:59 linux83 kernel: [ 8853.073115] >> [<ffffffff810f71b2>] warn_alloc_failed+0x102/0x1a0 >> 7484 Mar 6 00:20:59 linux83 kernel: [ 8853.073125] >> [<ffffffff810f8ca9>] __alloc_pages_slowpath+0x559/0x7f0 >> 7485 Mar 6 00:20:59 linux83 kernel: [ 8853.073131] >> [<ffffffff810f90f1>] __alloc_pages_nodemask+0x1b1/0x1c0 >> 7486 Mar 6 00:20:59 linux83 kernel: [ 8853.073144] >> [<ffffffff811312b5>] alloc_pages_current+0xa5/0x120 >> 7487 Mar 6 00:20:59 linux83 kernel: [ 8853.073152] >> [<ffffffff810f67c9>] __get_free_pages+0x9/0x50 >> 7488 Mar 6 00:20:59 linux83 kernel: [ 8853.073188] >> [<ffffffffa038332f>] sctp_ssnmap_new+0x5f/0xd0 [sctp] >> 7489 Mar 6 00:20:59 linux83 kernel: [ 8853.073260] >> [<ffffffffa03720b5>] sctp_process_init+0x395/0x3e0 [sctp] >> 7490 Mar 6 00:20:59 linux83 kernel: [ 8853.073277] >> [<ffffffffa036b981>] sctp_cmd_interpreter+0x2a1/0xf90 [sctp] >> 7491 Mar 6 00:20:59 linux83 kernel: [ 8853.073290] >> [<ffffffffa036c6a4>] sctp_side_effects+0x34/0xe0 [sctp] >> 7492 Mar 6 00:20:59 linux83 kernel: [ 8853.073302] >> [<ffffffffa036c7f5>] sctp_do_sm+0xa5/0xe0 [sctp] >> 7493 Mar 6 00:20:59 linux83 kernel: [ 8853.073315] >> [<ffffffffa037001c>] sctp_assoc_bh_rcv+0xbc/0x130 [sctp] >> 7494 Mar 6 00:20:59 linux83 kernel: [ 8853.073332] >> [<ffffffffa0382980>] sctp_backlog_rcv+0x60/0x140 [sctp] >> 7495 Mar 6 00:20:59 linux83 kernel: [ 8853.073361] >> [<ffffffff8137723c>] release_sock+0x5c/0x120 >> 7496 Mar 6 00:20:59 linux83 kernel: [ 8853.073372] >> [<ffffffffa037db48>] sctp_sendmsg+0x5e8/0x960 [sctp] >> 7497 Mar 6 00:20:59 linux83 kernel: [ 8853.073401] >> [<ffffffff81372bdb>] sock_sendmsg+0xdb/0x120 >> 7498 Mar 6 00:20:59 linux83 kernel: [ 8853.073407] >> [<ffffffff81373c8b>] __sys_sendmsg+0x37b/0x390 >> 7499 Mar 6 00:20:59 linux83 kernel: [ 8853.073412] >> [<ffffffff81373e72>] sys_sendmsg+0x42/0x80 >> 7500 Mar 6 00:20:59 linux83 kernel: [ 8853.073422] >> [<ffffffff81449692>] system_call_fastpath+0x16/0x1b >> 7501 Mar 6 00:20:59 linux83 kernel: [ 8853.074762] DWARF2 unwinder >> stuck at system_call_fastpath+0x16/0x1b >> 7502 Mar 6 00:20:59 linux83 kernel: [ 8853.074768] >> 7503 Mar 6 00:20:59 linux83 kernel: [ 8853.074770] Leftover inexact backtrace: >> 7504 Mar 6 00:20:59 linux83 kernel: [ 8853.074771] >> >> Regards, >> Jerry >> >> >> On Fri, Mar 6, 2015 at 9:41 AM, Neil Horman <nhorman@xxxxxxxxxxxxx> wrote: >> > On Fri, Mar 06, 2015 at 08:51:40AM -0800, Jerry Jerry wrote: >> >> Hi Neil, >> >> >> >> My apology that I didn't make it clear. There are actually two related >> >> issues, (1) ipv6 requirement, and (2) checksctp hangs. For 2nd issue, >> >> we are trying to recreate the problem and will get back to you once we >> >> have the trace. For the 1st issue, here is how we verified: >> >> >> >> using "vi /etc/modprobe.d/50-ipv6.conf" to comment out #install ipv6 >> >> /bin/true, and later using modprobe ipv6 to enable it. The following >> >> are our steps: >> >> >> >> linux165:~/sctp_test/lksctp-tools-1.0.16/src/withsctp >> >> # ./checksctp >> >> checksctp: Protocol not supported >> >> >> >> linux165:~/sctp_test/lksctp-tools-1.0.16/src/withsctp >> >> # vi /etc/modprobe.d/50-ipv6.conf (undo comment out ipv6) >> >> >> >> linux165:~/sctp_test/lksctp-tools-1.0.16/src/withsctp >> >> # modprobe ipv6 >> >> >> >> linux165:~/sctp_test/lksctp-tools-1.0.16/src/withsctp >> >> # ./checksctp >> >> SCTP supported >> >> >> > Sorry, didn't realize what you were asking. What I should say is that sctp has >> > no build time requriements on ipv6. That is to say you could disable ipv6 in >> > your kernel build and sctp should still work on ipv4 just fine. But if you do >> > what you suggest above, which is to say, build sctp with ipv6 support, and then >> > prevent the ipv6 module from loading, sctp won't just fall back to pretending it >> > can't talk over ipv6. It has load time symbol requirements that will prevent >> > the module from loading, which is why you get the EOPNOTSUPP error above. >> > >> > Neil >> > >> >> >> >> Regards, >> >> Jerry >> >> >> >> On Thu, Mar 5, 2015 at 6:04 AM, Neil Horman <nhorman@xxxxxxxxxxxxx> wrote: >> >> > On Wed, Mar 04, 2015 at 12:59:21PM -0800, Jerry Jerry wrote: >> >> >> Hello, >> >> >> >> >> >> We had a strange problem using lksctp-tool where checksctp would hang >> >> >> there on some of our machines and process cannot be killed anyway >> >> >> (with status d/d+). After some investigation, we found out that >> >> >> whether ipv6 is enabled could impact the behavior of the library. So, >> >> >> my question is that, is this a requirement by design or it just >> >> >> happens to occur that ipv6 is required? Any suggestion to bypass this >> >> >> (not to rely on ipv6) would be appreciated very much. >> >> >> >> >> >> Regards, >> >> >> Jerry >> >> > IIRC there should be no ipv6 requierment. >> >> > >> >> > Where does the checksctp tool hang? Is it in user space or the kernel? Can you >> >> > provide a backtrace, either ia gdb if its in userspace or sysrq in the kernel? >> >> > >> >> > Best >> >> > Neil >> >> > >> >> >> -- >> >> >> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in >> >> >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> >> >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> >> >> >> >> -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
