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
