* [LTP] [PATCH] syscalls/setsockopt05: associate receiver with destination address @ 2020-08-24 12:10 Jan Stancek 2020-08-24 14:42 ` Martin Doucha 0 siblings, 1 reply; 14+ messages in thread From: Jan Stancek @ 2020-08-24 12:10 UTC (permalink / raw) To: ltp to avoid sporadic ECONNREFUSED errors: safe_net.c:202: BROK: setsockopt05.c:70: send(6, 0x3ffcaf7d828, 4000, 32768) failed: ECONNREFUSED (111) Signed-off-by: Jan Stancek <jstancek@redhat.com> --- testcases/kernel/syscalls/setsockopt/setsockopt05.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/testcases/kernel/syscalls/setsockopt/setsockopt05.c b/testcases/kernel/syscalls/setsockopt/setsockopt05.c index e78ef236e337..469e5a64bf71 100644 --- a/testcases/kernel/syscalls/setsockopt/setsockopt05.c +++ b/testcases/kernel/syscalls/setsockopt/setsockopt05.c @@ -37,6 +37,7 @@ static void setup(void) int real_uid = getuid(); int real_gid = getgid(); int sock; + int port = TST_GET_UNUSED_PORT(AF_INET, SOCK_DGRAM); struct ifreq ifr; SAFE_UNSHARE(CLONE_NEWUSER); @@ -45,14 +46,14 @@ static void setup(void) SAFE_FILE_PRINTF("/proc/self/uid_map", "0 %d 1", real_uid); SAFE_FILE_PRINTF("/proc/self/gid_map", "0 %d 1", real_gid); - tst_init_sockaddr_inet_bin(&addr, INADDR_LOOPBACK, 12345); + tst_init_sockaddr_inet_bin(&addr, INADDR_LOOPBACK, port); sock = SAFE_SOCKET(AF_INET, SOCK_DGRAM, 0); strcpy(ifr.ifr_name, "lo"); ifr.ifr_mtu = 1500; SAFE_IOCTL(sock, SIOCSIFMTU, &ifr); ifr.ifr_flags = IFF_UP; SAFE_IOCTL(sock, SIOCSIFFLAGS, &ifr); - SAFE_CLOSE(sock); + SAFE_BIND(sock, (struct sockaddr *)&addr, sizeof(struct sockaddr)); } static void run(void) -- 2.18.1 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [LTP] [PATCH] syscalls/setsockopt05: associate receiver with destination address 2020-08-24 12:10 [LTP] [PATCH] syscalls/setsockopt05: associate receiver with destination address Jan Stancek @ 2020-08-24 14:42 ` Martin Doucha 2020-08-24 15:01 ` Jan Stancek 0 siblings, 1 reply; 14+ messages in thread From: Martin Doucha @ 2020-08-24 14:42 UTC (permalink / raw) To: ltp Hi, On 24. 08. 20 14:10, Jan Stancek wrote: > to avoid sporadic ECONNREFUSED errors: > safe_net.c:202: BROK: setsockopt05.c:70: send(6, 0x3ffcaf7d828, 4000, 32768) failed: ECONNREFUSED (111) > > Signed-off-by: Jan Stancek <jstancek@redhat.com> > --- > testcases/kernel/syscalls/setsockopt/setsockopt05.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/testcases/kernel/syscalls/setsockopt/setsockopt05.c b/testcases/kernel/syscalls/setsockopt/setsockopt05.c > index e78ef236e337..469e5a64bf71 100644 > --- a/testcases/kernel/syscalls/setsockopt/setsockopt05.c > +++ b/testcases/kernel/syscalls/setsockopt/setsockopt05.c > @@ -37,6 +37,7 @@ static void setup(void) > int real_uid = getuid(); > int real_gid = getgid(); > int sock; > + int port = TST_GET_UNUSED_PORT(AF_INET, SOCK_DGRAM); > struct ifreq ifr; > > SAFE_UNSHARE(CLONE_NEWUSER); > @@ -45,14 +46,14 @@ static void setup(void) > SAFE_FILE_PRINTF("/proc/self/uid_map", "0 %d 1", real_uid); > SAFE_FILE_PRINTF("/proc/self/gid_map", "0 %d 1", real_gid); > > - tst_init_sockaddr_inet_bin(&addr, INADDR_LOOPBACK, 12345); > + tst_init_sockaddr_inet_bin(&addr, INADDR_LOOPBACK, port); Please don't use TST_GET_UNUSED_PORT() this way. The correct way to do this is to set port to 0 and then read the address back using SAFE_GETSOCKNAME() after bind(). It's the same amount of code but without any race conditions. > sock = SAFE_SOCKET(AF_INET, SOCK_DGRAM, 0); > strcpy(ifr.ifr_name, "lo"); > ifr.ifr_mtu = 1500; > SAFE_IOCTL(sock, SIOCSIFMTU, &ifr); > ifr.ifr_flags = IFF_UP; > SAFE_IOCTL(sock, SIOCSIFFLAGS, &ifr); > - SAFE_CLOSE(sock); Don't forget to close the socket in cleanup(). > + SAFE_BIND(sock, (struct sockaddr *)&addr, sizeof(struct sockaddr)); > } > > static void run(void) > Though I wonder whether setsockopt(SO_NO_CHECK, 1) is really supposed to flush the partial packet. Are you sure it's not a bug in the kernel? -- Martin Doucha mdoucha@suse.cz QA Engineer for Software Maintenance SUSE LINUX, s.r.o. CORSO IIa Krizikova 148/34 186 00 Prague 8 Czech Republic ^ permalink raw reply [flat|nested] 14+ messages in thread
* [LTP] [PATCH] syscalls/setsockopt05: associate receiver with destination address 2020-08-24 14:42 ` Martin Doucha @ 2020-08-24 15:01 ` Jan Stancek 2020-08-24 15:21 ` Martin Doucha 0 siblings, 1 reply; 14+ messages in thread From: Jan Stancek @ 2020-08-24 15:01 UTC (permalink / raw) To: ltp ----- Original Message ----- > Hi, > > On 24. 08. 20 14:10, Jan Stancek wrote: > > to avoid sporadic ECONNREFUSED errors: > > safe_net.c:202: BROK: setsockopt05.c:70: send(6, 0x3ffcaf7d828, 4000, > > 32768) failed: ECONNREFUSED (111) > > > > Signed-off-by: Jan Stancek <jstancek@redhat.com> > > --- > > testcases/kernel/syscalls/setsockopt/setsockopt05.c | 5 +++-- > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > diff --git a/testcases/kernel/syscalls/setsockopt/setsockopt05.c > > b/testcases/kernel/syscalls/setsockopt/setsockopt05.c > > index e78ef236e337..469e5a64bf71 100644 > > --- a/testcases/kernel/syscalls/setsockopt/setsockopt05.c > > +++ b/testcases/kernel/syscalls/setsockopt/setsockopt05.c > > @@ -37,6 +37,7 @@ static void setup(void) > > int real_uid = getuid(); > > int real_gid = getgid(); > > int sock; > > + int port = TST_GET_UNUSED_PORT(AF_INET, SOCK_DGRAM); > > struct ifreq ifr; > > > > SAFE_UNSHARE(CLONE_NEWUSER); > > @@ -45,14 +46,14 @@ static void setup(void) > > SAFE_FILE_PRINTF("/proc/self/uid_map", "0 %d 1", real_uid); > > SAFE_FILE_PRINTF("/proc/self/gid_map", "0 %d 1", real_gid); > > > > - tst_init_sockaddr_inet_bin(&addr, INADDR_LOOPBACK, 12345); > > + tst_init_sockaddr_inet_bin(&addr, INADDR_LOOPBACK, port); > > Please don't use TST_GET_UNUSED_PORT() this way. The correct way to do > this is to set port to 0 and then read the address back using > SAFE_GETSOCKNAME() after bind(). It's the same amount of code but > without any race conditions. Fair point. > > > sock = SAFE_SOCKET(AF_INET, SOCK_DGRAM, 0); > > strcpy(ifr.ifr_name, "lo"); > > ifr.ifr_mtu = 1500; > > SAFE_IOCTL(sock, SIOCSIFMTU, &ifr); > > ifr.ifr_flags = IFF_UP; > > SAFE_IOCTL(sock, SIOCSIFFLAGS, &ifr); > > - SAFE_CLOSE(sock); > > Don't forget to close the socket in cleanup(). > > > + SAFE_BIND(sock, (struct sockaddr *)&addr, sizeof(struct sockaddr)); > > } > > > > static void run(void) > > > > Though I wonder whether setsockopt(SO_NO_CHECK, 1) is really supposed to > flush the partial packet. Are you sure it's not a bug in the kernel? I assumed it's from previous one, not partial one. From man(7) udp: ECONNREFUSED No receiver was associated with the destination address. This might be caused by a previous packet sent over the socket. ^ permalink raw reply [flat|nested] 14+ messages in thread
* [LTP] [PATCH] syscalls/setsockopt05: associate receiver with destination address 2020-08-24 15:01 ` Jan Stancek @ 2020-08-24 15:21 ` Martin Doucha 2020-08-24 16:11 ` Jan Stancek 0 siblings, 1 reply; 14+ messages in thread From: Martin Doucha @ 2020-08-24 15:21 UTC (permalink / raw) To: ltp On 24. 08. 20 17:01, Jan Stancek wrote: > I assumed it's from previous one, not partial one. From man(7) udp: > > ECONNREFUSED > No receiver was associated with the destination address. > This might be caused by a previous packet sent over the socket. > Wait, looking closer at the error message, it looks like send(MSG_MORE) is broken on your test kernel. Let me quote the man page here: > MSG_MORE (since Linux 2.4.4) > The caller has more data to send. This flag is used with TCP > sockets to obtain the same effect as the TCP_CORK socket option > (see tcp(7)), with the difference that this flag can be set on a > per-call basis. > > Since Linux 2.6, this flag is also supported for UDP sockets, > and informs the kernel to package all of the data sent in calls > with this flag set into a single datagram which is transmitted > only when a call is performed that does not specify this flag. > (See also the UDP_CORK socket option described in udp(7).) The data from the SAFE_SEND() call are supposed to stay in kernel buffer until the send() call where we (intentionally) ignore the return value. -- Martin Doucha mdoucha@suse.cz QA Engineer for Software Maintenance SUSE LINUX, s.r.o. CORSO IIa Krizikova 148/34 186 00 Prague 8 Czech Republic ^ permalink raw reply [flat|nested] 14+ messages in thread
* [LTP] [PATCH] syscalls/setsockopt05: associate receiver with destination address 2020-08-24 15:21 ` Martin Doucha @ 2020-08-24 16:11 ` Jan Stancek 2020-08-25 9:43 ` Martin Doucha 0 siblings, 1 reply; 14+ messages in thread From: Jan Stancek @ 2020-08-24 16:11 UTC (permalink / raw) To: ltp ----- Original Message ----- > On 24. 08. 20 17:01, Jan Stancek wrote: > > I assumed it's from previous one, not partial one. From man(7) udp: > > > > ECONNREFUSED > > No receiver was associated with the destination address. > > This might be caused by a previous packet sent over the > > socket. > > > > Wait, looking closer at the error message, it looks like send(MSG_MORE) > is broken on your test kernel. Let me quote the man page here: Aren't we getting propagated ICMP error to send() from previous iteration of the loop? Per https://tools.ietf.org/html/rfc1122#page-78 The application is also responsible to avoid confusion from a delayed ICMP error message resulting from an earlier use of the same port(s). ^ permalink raw reply [flat|nested] 14+ messages in thread
* [LTP] [PATCH] syscalls/setsockopt05: associate receiver with destination address 2020-08-24 16:11 ` Jan Stancek @ 2020-08-25 9:43 ` Martin Doucha 2020-08-25 13:38 ` Jan Stancek 0 siblings, 1 reply; 14+ messages in thread From: Martin Doucha @ 2020-08-25 9:43 UTC (permalink / raw) To: ltp On 24. 08. 20 18:11, Jan Stancek wrote: > Aren't we getting propagated ICMP error to send() from previous iteration > of the loop? > > Per https://tools.ietf.org/html/rfc1122#page-78 > The application is also responsible to avoid confusion from a delayed ICMP > error message resulting from an earlier use of the same port(s). The test is using the loopback address. There should be no delay. We're running this test daily on 7 different kernel versions and 4 different archs and I've never seen it fail with ECONNREFUSED, ever. But you can prove me wrong by adding a few debug prints around both send() calls. -- Martin Doucha mdoucha@suse.cz QA Engineer for Software Maintenance SUSE LINUX, s.r.o. CORSO IIa Krizikova 148/34 186 00 Prague 8 Czech Republic ^ permalink raw reply [flat|nested] 14+ messages in thread
* [LTP] [PATCH] syscalls/setsockopt05: associate receiver with destination address 2020-08-25 9:43 ` Martin Doucha @ 2020-08-25 13:38 ` Jan Stancek 2020-08-26 10:08 ` Martin Doucha 2020-08-26 10:39 ` [LTP] [PATCH] " Martin Doucha 0 siblings, 2 replies; 14+ messages in thread From: Jan Stancek @ 2020-08-25 13:38 UTC (permalink / raw) To: ltp ----- Original Message ----- > On 24. 08. 20 18:11, Jan Stancek wrote: > > Aren't we getting propagated ICMP error to send() from previous iteration > > of the loop? > > > > Per https://tools.ietf.org/html/rfc1122#page-78 > > The application is also responsible to avoid confusion from a delayed > > ICMP > > error message resulting from an earlier use of the same port(s). > > The test is using the loopback address. There should be no delay. We're > running this test daily on 7 different kernel versions and 4 different > archs and I've never seen it fail with ECONNREFUSED, ever. Similar here, it runs daily dozens of times, but appears to fail sporadically only on s390x. > > But you can prove me wrong by adding a few debug prints around both > send() calls. 1. extra prints 65 for (i = 0; i < 1000; i++) { 66 sock = SAFE_SOCKET(AF_INET, SOCK_DGRAM, 0); 67 SAFE_CONNECT(sock, (struct sockaddr *)&addr, sizeof(addr)); 68 printf("1 %d\n", i); 69 SAFE_SEND(1, sock, buf, BUFSIZE, MSG_MORE); 70 printf("2 %d\n", i); 71 SAFE_SETSOCKOPT_INT(sock, SOL_SOCKET, SO_NO_CHECK, 1); 72 printf("3 %d\n", i); 73 send(sock, buf, 1, 0); 74 printf("4 %d\n", i); 75 SAFE_CLOSE(sock); 1 246 2 246 3 246 4 246 1 247 2 247 3 247 4 247 1 248 safe_net.c:202: BROK: setsockopt05.c:69: send(3, 0x3ffc397db88, 4000, 32768) failed: ECONNREFUSED (111) 2. SO_NO_CHECK doesn't matter, following fails: sock = SAFE_SOCKET(AF_INET, SOCK_DGRAM, 0); SAFE_CONNECT(sock, (struct sockaddr *)&addr, sizeof(addr)); SAFE_SEND(1, sock, buf, BUFSIZE, MSG_MORE); send(sock, buf, 1, 0); SAFE_CLOSE(sock); 3. MSG_MORE doesn't matter, following fails: sock = SAFE_SOCKET(AF_INET, SOCK_DGRAM, 0); SAFE_CONNECT(sock, (struct sockaddr *)&addr, sizeof(addr)); SAFE_SEND(1, sock, buf, BUFSIZE, 0); SAFE_CLOSE(sock); Regards, Jan ^ permalink raw reply [flat|nested] 14+ messages in thread
* [LTP] [PATCH] syscalls/setsockopt05: associate receiver with destination address 2020-08-25 13:38 ` Jan Stancek @ 2020-08-26 10:08 ` Martin Doucha 2020-08-26 10:20 ` Martin Doucha 2020-08-26 10:39 ` [LTP] [PATCH] " Martin Doucha 1 sibling, 1 reply; 14+ messages in thread From: Martin Doucha @ 2020-08-26 10:08 UTC (permalink / raw) To: ltp Let's see if it's really a delayed ICMP message. Can you reproduce the error after applying this patch? In the meantime, I'll write a test for send(MSG_MORE). --- testcases/kernel/syscalls/setsockopt/setsockopt05.c | 1 + 1 file changed, 1 insertion(+) diff --git a/testcases/kernel/syscalls/setsockopt/setsockopt05.c b/testcases/kernel/syscalls/setsockopt/setsockopt05.c index e78ef236e..594178744 100644 --- a/testcases/kernel/syscalls/setsockopt/setsockopt05.c +++ b/testcases/kernel/syscalls/setsockopt/setsockopt05.c @@ -63,6 +63,7 @@ static void run(void) memset(buf, 0x42, BUFSIZE); for (i = 0; i < 1000; i++) { + addr.sin_port = 12345 + i; sock = SAFE_SOCKET(AF_INET, SOCK_DGRAM, 0); SAFE_CONNECT(sock, (struct sockaddr *)&addr, sizeof(addr)); SAFE_SEND(1, sock, buf, BUFSIZE, MSG_MORE); -- 2.28.0 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [LTP] [PATCH] syscalls/setsockopt05: associate receiver with destination address 2020-08-26 10:08 ` Martin Doucha @ 2020-08-26 10:20 ` Martin Doucha 0 siblings, 0 replies; 14+ messages in thread From: Martin Doucha @ 2020-08-26 10:20 UTC (permalink / raw) To: ltp Sorry, ignore this patch, I meant to add a bind() there to change the source port... On 26. 08. 20 12:08, Martin Doucha wrote: > Let's see if it's really a delayed ICMP message. Can you reproduce the error > after applying this patch? > > In the meantime, I'll write a test for send(MSG_MORE). > > --- > testcases/kernel/syscalls/setsockopt/setsockopt05.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/testcases/kernel/syscalls/setsockopt/setsockopt05.c b/testcases/kernel/syscalls/setsockopt/setsockopt05.c > index e78ef236e..594178744 100644 > --- a/testcases/kernel/syscalls/setsockopt/setsockopt05.c > +++ b/testcases/kernel/syscalls/setsockopt/setsockopt05.c > @@ -63,6 +63,7 @@ static void run(void) > memset(buf, 0x42, BUFSIZE); > > for (i = 0; i < 1000; i++) { > + addr.sin_port = 12345 + i; > sock = SAFE_SOCKET(AF_INET, SOCK_DGRAM, 0); > SAFE_CONNECT(sock, (struct sockaddr *)&addr, sizeof(addr)); > SAFE_SEND(1, sock, buf, BUFSIZE, MSG_MORE); > -- Martin Doucha mdoucha@suse.cz QA Engineer for Software Maintenance SUSE LINUX, s.r.o. CORSO IIa Krizikova 148/34 186 00 Prague 8 Czech Republic ^ permalink raw reply [flat|nested] 14+ messages in thread
* [LTP] [PATCH] Re: [PATCH] syscalls/setsockopt05: associate receiver with destination address 2020-08-25 13:38 ` Jan Stancek 2020-08-26 10:08 ` Martin Doucha @ 2020-08-26 10:39 ` Martin Doucha 2020-08-27 12:14 ` [LTP] [PATCH v2] " Jan Stancek 1 sibling, 1 reply; 14+ messages in thread From: Martin Doucha @ 2020-08-26 10:39 UTC (permalink / raw) To: ltp OK, here's the correct test patch. The source port changes on every iteration so different send() calls shouldn't interfere with one another. If you get ECONNREFUSED with this patch applied, it's caused by broken implementation of send(MSG_MORE), not delayed ICMP packets. If this patch prevents the error, resubmit your patch with fixes. I'll write the test for send(MSG_MORE) either way because if the flag isn't honored by the kernel, setsockopt05 will be useless. --- testcases/kernel/syscalls/setsockopt/setsockopt05.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/testcases/kernel/syscalls/setsockopt/setsockopt05.c b/testcases/kernel/syscalls/setsockopt/setsockopt05.c index e78ef236e..698396390 100644 --- a/testcases/kernel/syscalls/setsockopt/setsockopt05.c +++ b/testcases/kernel/syscalls/setsockopt/setsockopt05.c @@ -64,6 +64,9 @@ static void run(void) for (i = 0; i < 1000; i++) { sock = SAFE_SOCKET(AF_INET, SOCK_DGRAM, 0); + addr.sin_port = 12346 + i; + SAFE_BIND(sock, (struct sockaddr *)&addr, sizeof(addr)); + addr.sin_port = 12345; SAFE_CONNECT(sock, (struct sockaddr *)&addr, sizeof(addr)); SAFE_SEND(1, sock, buf, BUFSIZE, MSG_MORE); SAFE_SETSOCKOPT_INT(sock, SOL_SOCKET, SO_NO_CHECK, 1); -- 2.28.0 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [LTP] [PATCH v2] syscalls/setsockopt05: associate receiver with destination address 2020-08-26 10:39 ` [LTP] [PATCH] " Martin Doucha @ 2020-08-27 12:14 ` Jan Stancek 2020-08-27 15:55 ` Martin Doucha 0 siblings, 1 reply; 14+ messages in thread From: Jan Stancek @ 2020-08-27 12:14 UTC (permalink / raw) To: ltp to avoid sporadic ECONNREFUSED errors (caused by delayed ICMP): safe_net.c:202: BROK: setsockopt05.c:70: send(6, 0x3ffcaf7d828, 4000, 32768) failed: ECONNREFUSED (111) per man(7) udp: ECONNREFUSED No receiver was associated with the destination address. This might be caused by a previous packet sent over the socket. per https://tools.ietf.org/html/rfc1122#page-78 The application is also responsible to avoid confusion from a delayed ICMP error message resulting from an earlier use of the same port(s). Signed-off-by: Jan Stancek <jstancek@redhat.com> --- .../kernel/syscalls/setsockopt/setsockopt05.c | 23 ++++++++++++++----- 1 file changed, 17 insertions(+), 6 deletions(-) diff --git a/testcases/kernel/syscalls/setsockopt/setsockopt05.c b/testcases/kernel/syscalls/setsockopt/setsockopt05.c index e78ef236e337..0b7ff39d2663 100644 --- a/testcases/kernel/syscalls/setsockopt/setsockopt05.c +++ b/testcases/kernel/syscalls/setsockopt/setsockopt05.c @@ -31,13 +31,14 @@ #define BUFSIZE 4000 static struct sockaddr_in addr; +static int dst_sock = -1; static void setup(void) { int real_uid = getuid(); int real_gid = getgid(); - int sock; struct ifreq ifr; + socklen_t addrlen = sizeof(addr); SAFE_UNSHARE(CLONE_NEWUSER); SAFE_UNSHARE(CLONE_NEWNET); @@ -45,14 +46,23 @@ static void setup(void) SAFE_FILE_PRINTF("/proc/self/uid_map", "0 %d 1", real_uid); SAFE_FILE_PRINTF("/proc/self/gid_map", "0 %d 1", real_gid); - tst_init_sockaddr_inet_bin(&addr, INADDR_LOOPBACK, 12345); - sock = SAFE_SOCKET(AF_INET, SOCK_DGRAM, 0); + tst_init_sockaddr_inet_bin(&addr, INADDR_LOOPBACK, 0); + dst_sock = SAFE_SOCKET(AF_INET, SOCK_DGRAM, 0); + strcpy(ifr.ifr_name, "lo"); ifr.ifr_mtu = 1500; - SAFE_IOCTL(sock, SIOCSIFMTU, &ifr); + SAFE_IOCTL(dst_sock, SIOCSIFMTU, &ifr); ifr.ifr_flags = IFF_UP; - SAFE_IOCTL(sock, SIOCSIFFLAGS, &ifr); - SAFE_CLOSE(sock); + SAFE_IOCTL(dst_sock, SIOCSIFFLAGS, &ifr); + + SAFE_BIND(dst_sock, (struct sockaddr *)&addr, addrlen); + SAFE_GETSOCKNAME(dst_sock, (struct sockaddr*)&addr, &addrlen); +} + +static void cleanup(void) +{ + if (dst_sock != -1) + SAFE_CLOSE(dst_sock); } static void run(void) @@ -82,6 +92,7 @@ static void run(void) static struct tst_test test = { .test_all = run, .setup = setup, + .cleanup = cleanup, .taint_check = TST_TAINT_W | TST_TAINT_D, .needs_kconfigs = (const char *[]) { "CONFIG_USER_NS=y", -- 2.18.1 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [LTP] [PATCH v2] syscalls/setsockopt05: associate receiver with destination address 2020-08-27 12:14 ` [LTP] [PATCH v2] " Jan Stancek @ 2020-08-27 15:55 ` Martin Doucha 2020-08-27 15:58 ` Jan Stancek 0 siblings, 1 reply; 14+ messages in thread From: Martin Doucha @ 2020-08-27 15:55 UTC (permalink / raw) To: ltp Hi, I assume that cycling through different source ports prevented the issue? Reviewed-by: Martin Doucha <mdoucha@suse.cz> On 27. 08. 20 14:14, Jan Stancek wrote: > to avoid sporadic ECONNREFUSED errors (caused by delayed ICMP): > safe_net.c:202: BROK: setsockopt05.c:70: send(6, 0x3ffcaf7d828, 4000, 32768) failed: ECONNREFUSED (111) > > per man(7) udp: > ECONNREFUSED > No receiver was associated with the destination address. > This might be caused by a previous packet sent over the socket. > > per https://tools.ietf.org/html/rfc1122#page-78 > The application is also responsible to avoid confusion from a delayed ICMP > error message resulting from an earlier use of the same port(s). > > Signed-off-by: Jan Stancek <jstancek@redhat.com> > --- > .../kernel/syscalls/setsockopt/setsockopt05.c | 23 ++++++++++++++----- > 1 file changed, 17 insertions(+), 6 deletions(-) > > diff --git a/testcases/kernel/syscalls/setsockopt/setsockopt05.c b/testcases/kernel/syscalls/setsockopt/setsockopt05.c > index e78ef236e337..0b7ff39d2663 100644 > --- a/testcases/kernel/syscalls/setsockopt/setsockopt05.c > +++ b/testcases/kernel/syscalls/setsockopt/setsockopt05.c > @@ -31,13 +31,14 @@ > #define BUFSIZE 4000 > > static struct sockaddr_in addr; > +static int dst_sock = -1; > > static void setup(void) > { > int real_uid = getuid(); > int real_gid = getgid(); > - int sock; > struct ifreq ifr; > + socklen_t addrlen = sizeof(addr); > > SAFE_UNSHARE(CLONE_NEWUSER); > SAFE_UNSHARE(CLONE_NEWNET); > @@ -45,14 +46,23 @@ static void setup(void) > SAFE_FILE_PRINTF("/proc/self/uid_map", "0 %d 1", real_uid); > SAFE_FILE_PRINTF("/proc/self/gid_map", "0 %d 1", real_gid); > > - tst_init_sockaddr_inet_bin(&addr, INADDR_LOOPBACK, 12345); > - sock = SAFE_SOCKET(AF_INET, SOCK_DGRAM, 0); > + tst_init_sockaddr_inet_bin(&addr, INADDR_LOOPBACK, 0); > + dst_sock = SAFE_SOCKET(AF_INET, SOCK_DGRAM, 0); > + > strcpy(ifr.ifr_name, "lo"); > ifr.ifr_mtu = 1500; > - SAFE_IOCTL(sock, SIOCSIFMTU, &ifr); > + SAFE_IOCTL(dst_sock, SIOCSIFMTU, &ifr); > ifr.ifr_flags = IFF_UP; > - SAFE_IOCTL(sock, SIOCSIFFLAGS, &ifr); > - SAFE_CLOSE(sock); > + SAFE_IOCTL(dst_sock, SIOCSIFFLAGS, &ifr); > + > + SAFE_BIND(dst_sock, (struct sockaddr *)&addr, addrlen); > + SAFE_GETSOCKNAME(dst_sock, (struct sockaddr*)&addr, &addrlen); > +} > + > +static void cleanup(void) > +{ > + if (dst_sock != -1) > + SAFE_CLOSE(dst_sock); > } > > static void run(void) > @@ -82,6 +92,7 @@ static void run(void) > static struct tst_test test = { > .test_all = run, > .setup = setup, > + .cleanup = cleanup, > .taint_check = TST_TAINT_W | TST_TAINT_D, > .needs_kconfigs = (const char *[]) { > "CONFIG_USER_NS=y", > -- Martin Doucha mdoucha@suse.cz QA Engineer for Software Maintenance SUSE LINUX, s.r.o. CORSO IIa Krizikova 148/34 186 00 Prague 8 Czech Republic ^ permalink raw reply [flat|nested] 14+ messages in thread
* [LTP] [PATCH v2] syscalls/setsockopt05: associate receiver with destination address 2020-08-27 15:55 ` Martin Doucha @ 2020-08-27 15:58 ` Jan Stancek 2020-08-27 17:55 ` Jan Stancek 0 siblings, 1 reply; 14+ messages in thread From: Jan Stancek @ 2020-08-27 15:58 UTC (permalink / raw) To: ltp ----- Original Message ----- > Hi, > I assume that cycling through different source ports prevented the issue? Yes, it did, it ran fine over night. > > Reviewed-by: Martin Doucha <mdoucha@suse.cz> > > On 27. 08. 20 14:14, Jan Stancek wrote: > > to avoid sporadic ECONNREFUSED errors (caused by delayed ICMP): > > safe_net.c:202: BROK: setsockopt05.c:70: send(6, 0x3ffcaf7d828, 4000, > > 32768) failed: ECONNREFUSED (111) > > > > per man(7) udp: > > ECONNREFUSED > > No receiver was associated with the destination address. > > This might be caused by a previous packet sent over the socket. > > > > per https://tools.ietf.org/html/rfc1122#page-78 > > The application is also responsible to avoid confusion from a delayed > > ICMP > > error message resulting from an earlier use of the same port(s). > > > > Signed-off-by: Jan Stancek <jstancek@redhat.com> > > --- > > .../kernel/syscalls/setsockopt/setsockopt05.c | 23 ++++++++++++++----- > > 1 file changed, 17 insertions(+), 6 deletions(-) > > > > diff --git a/testcases/kernel/syscalls/setsockopt/setsockopt05.c > > b/testcases/kernel/syscalls/setsockopt/setsockopt05.c > > index e78ef236e337..0b7ff39d2663 100644 > > --- a/testcases/kernel/syscalls/setsockopt/setsockopt05.c > > +++ b/testcases/kernel/syscalls/setsockopt/setsockopt05.c > > @@ -31,13 +31,14 @@ > > #define BUFSIZE 4000 > > > > static struct sockaddr_in addr; > > +static int dst_sock = -1; > > > > static void setup(void) > > { > > int real_uid = getuid(); > > int real_gid = getgid(); > > - int sock; > > struct ifreq ifr; > > + socklen_t addrlen = sizeof(addr); > > > > SAFE_UNSHARE(CLONE_NEWUSER); > > SAFE_UNSHARE(CLONE_NEWNET); > > @@ -45,14 +46,23 @@ static void setup(void) > > SAFE_FILE_PRINTF("/proc/self/uid_map", "0 %d 1", real_uid); > > SAFE_FILE_PRINTF("/proc/self/gid_map", "0 %d 1", real_gid); > > > > - tst_init_sockaddr_inet_bin(&addr, INADDR_LOOPBACK, 12345); > > - sock = SAFE_SOCKET(AF_INET, SOCK_DGRAM, 0); > > + tst_init_sockaddr_inet_bin(&addr, INADDR_LOOPBACK, 0); > > + dst_sock = SAFE_SOCKET(AF_INET, SOCK_DGRAM, 0); > > + > > strcpy(ifr.ifr_name, "lo"); > > ifr.ifr_mtu = 1500; > > - SAFE_IOCTL(sock, SIOCSIFMTU, &ifr); > > + SAFE_IOCTL(dst_sock, SIOCSIFMTU, &ifr); > > ifr.ifr_flags = IFF_UP; > > - SAFE_IOCTL(sock, SIOCSIFFLAGS, &ifr); > > - SAFE_CLOSE(sock); > > + SAFE_IOCTL(dst_sock, SIOCSIFFLAGS, &ifr); > > + > > + SAFE_BIND(dst_sock, (struct sockaddr *)&addr, addrlen); > > + SAFE_GETSOCKNAME(dst_sock, (struct sockaddr*)&addr, &addrlen); > > +} > > + > > +static void cleanup(void) > > +{ > > + if (dst_sock != -1) > > + SAFE_CLOSE(dst_sock); > > } > > > > static void run(void) > > @@ -82,6 +92,7 @@ static void run(void) > > static struct tst_test test = { > > .test_all = run, > > .setup = setup, > > + .cleanup = cleanup, > > .taint_check = TST_TAINT_W | TST_TAINT_D, > > .needs_kconfigs = (const char *[]) { > > "CONFIG_USER_NS=y", > > > > > -- > Martin Doucha mdoucha@suse.cz > QA Engineer for Software Maintenance > SUSE LINUX, s.r.o. > CORSO IIa > Krizikova 148/34 > 186 00 Prague 8 > Czech Republic > > ^ permalink raw reply [flat|nested] 14+ messages in thread
* [LTP] [PATCH v2] syscalls/setsockopt05: associate receiver with destination address 2020-08-27 15:58 ` Jan Stancek @ 2020-08-27 17:55 ` Jan Stancek 0 siblings, 0 replies; 14+ messages in thread From: Jan Stancek @ 2020-08-27 17:55 UTC (permalink / raw) To: ltp ----- Original Message ----- > Hi, > I assume that cycling through different source ports prevented the issue? Yes, it did, it ran fine over night. > > Reviewed-by: Martin Doucha <mdoucha@suse.cz> Pushed. Thanks, Jan ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-08-27 17:55 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-08-24 12:10 [LTP] [PATCH] syscalls/setsockopt05: associate receiver with destination address Jan Stancek 2020-08-24 14:42 ` Martin Doucha 2020-08-24 15:01 ` Jan Stancek 2020-08-24 15:21 ` Martin Doucha 2020-08-24 16:11 ` Jan Stancek 2020-08-25 9:43 ` Martin Doucha 2020-08-25 13:38 ` Jan Stancek 2020-08-26 10:08 ` Martin Doucha 2020-08-26 10:20 ` Martin Doucha 2020-08-26 10:39 ` [LTP] [PATCH] " Martin Doucha 2020-08-27 12:14 ` [LTP] [PATCH v2] " Jan Stancek 2020-08-27 15:55 ` Martin Doucha 2020-08-27 15:58 ` Jan Stancek 2020-08-27 17:55 ` Jan Stancek
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox