Thanks, Neil, we'll verify this. Regards, Jerry On Sun, Mar 8, 2015 at 6:03 AM, Neil Horman <nhorman@xxxxxxxxxxxxx> wrote: > On Sat, Mar 07, 2015 at 09:48:38PM -0800, Jerry Jerry wrote: >> It's running on 3.0.13. For certain reason, we have to run it on some >> "older" version of kernel. >> > > Seems like this: > https://bugzilla.kernel.org/show_bug.cgi?id=14709 > >> 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
