2017-01-17 19:08 GMT+01:00 Xin Long <lucien.xin@xxxxxxxxx>: > On Wed, Jan 18, 2017 at 1:55 AM, Julian Cordes <julian.cordes@xxxxxxxxx> wrote: >> 2017-01-17 18:44 GMT+01:00 Xin Long <lucien.xin@xxxxxxxxx>: >>> On Wed, Jan 18, 2017 at 1:38 AM, Julian Cordes <julian.cordes@xxxxxxxxx> wrote: >>>> 2017-01-17 18:30 GMT+01:00 Xin Long <lucien.xin@xxxxxxxxx>: >>>>> On Tue, Jan 17, 2017 at 9:10 PM, Julian Cordes <julian.cordes@xxxxxxxxx> wrote: >>>>>> Somehow after calling sctp_sendmsg after calling shutdown with SHUT_WR a >>>>>> resource is not freed anymore. >>>>>> >>>>>> I can reproduce the following behaviour: >>>>>> When running for example the following test case >>>>>> https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/sender-side-implementation/shutdown-tests/ttl-policy/shutdown-14.pkt >>>>>> on my machine, it succeeds the first time. This means that the test case >>>>>> worked as expected. But if I run the same test case >>>>>> on the same machine again then the bind-call in the test-case will fail. >>>>>> I waited longer than 30 minutes but only a reboot of the operating >>>>>> system seems to help in this case. >>>>>> >>>>>> See the following test-cases that all reproduce this issue. All call >>>>>> sctp_sendmsg after calling shutdown, therefore i suspect >>>>>> that this is the cause of the issue. >>>>> I think it's a old issue, the latest kernel has no this issue any more. >>>>> can you give it a try ? >>>>> >>>> Hi, >>>> i just ran the test-case >>>> https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/sender-side-implementation/shutdown-tests/ttl-policy/shutdown-14.pkt >>>> on a recent archlinux kernel: >>>> $ uname -a >>>> Linux localhost 4.8.13-1-ARCH #1 SMP PREEMPT Fri Dec 9 07:24:34 CET >>>> 2016 x86_64 GNU/Linux >>>> >>>> The problem still exists. The second time i ran the test case, i got >>>> as a result: >>>> shutdown-14.pkt:78: runtime error in bind call: Expected result 0 but >>>> got -1 with errno 98 (Address already in use) >>>> >>> I meant upstream latest kernel: >>> git clone git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git >>> >>> it's already v4.10-rc3 >>> you may need to rebuild. :) >>> >>> >> Hi, >> okay. I have never rebuild a complete linux kernel. Do i just have to >> clone the specified repository and then run make? >> >> Maybe someone that has already v4.10-rc3 can clone packetdrill from >> https://github.com/nplab/packetdrill and run the specified test-case. >> If it works multiple times then this has already been fixed, if the >> bind calls fails the second time then the problem is still there...! > yeah, in my env, it works well with the latest kernel. > > but I think it's a blocker for your test script, you may still > want to build the latest kernel. > > https://kernelnewbies.org/KernelBuild : > part "Setting up your kernel configuration" and > part "Building the kernel" > > > I have now build the kernel from git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git and can confirm that this issue is resolved with the latest kernel. I can now run the test scripts multiples times and it works as expected on my machine. >>>>>> >>>>>> Testscripts available at: >>>>>> https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/sender-side-implementation/shutdown-tests/ttl-policy/shutdown-14.pkt >>>>>> https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/sender-side-implementation/shutdown-tests/ttl-policy/shutdown-1.pkt >>>>>> https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/sender-side-implementation/shutdown-tests/ttl-policy/shutdown-2.pkt >>>>>> https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/sender-side-implementation/shutdown-received-tests/ttl-policy/shutdown-1.pkt >>>>>> https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/sender-side-implementation/shutdown-received-tests/ttl-policy/shutdown-2.pkt -- 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
