gentoo resync : 18.05.2019

2 files changed, 81 insertions, 0 deletions

diff --git a/sys-apps/systemd/files/242-gcc-9.patch b/sys-apps/systemd/files/242-gcc-9.patch
new file mode 100644
index 000000000000..e12d65718238
--- /dev/null
+++ b/sys-apps/systemd/files/242-gcc-9.patch
@@ -0,0 +1,35 @@
+From c98b3545008d8e984ab456dcf79787418fcbfe13 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= <zbyszek@in.waw.pl>
+Date: Tue, 7 May 2019 13:46:55 +0200
+Subject: [PATCH] network: remove redunant link name in message
+
+Fixes #12454.
+
+gcc was complaining that the link->ifname argument is NULL. Adding
+assert(link->ifname) right before the call has no effect. It seems that
+gcc is confused by the fact that log_link_warning_errno() internally
+calls log_object(), with link->ifname passed as the object. log_object()
+is also a macro and is does a check whether the passed object is NULL.
+So we have a check if something is NULL right next an unconditional use
+of it where it cannot be NULL. I think it's a bug in gcc.
+
+Anyway, we don't need to use link->ifname here. log_object() already prepends
+the object name to the message.
+---
+ src/network/networkd-link.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
+index 533193ac932..6fc82940033 100644
+--- a/src/network/networkd-link.c
++++ b/src/network/networkd-link.c
+@@ -338,8 +338,7 @@ static int link_enable_ipv6(Link *link) {
+ 
+         r = sysctl_write_ip_property_boolean(AF_INET6, link->ifname, "disable_ipv6", disabled);
+         if (r < 0)
+-                log_link_warning_errno(link, r, "Cannot %s IPv6 for interface %s: %m",
+-                                       enable_disable(!disabled), link->ifname);
++                log_link_warning_errno(link, r, "Cannot %s IPv6: %m", enable_disable(!disabled));
+         else
+                 log_link_info(link, "IPv6 successfully %sd", enable_disable(!disabled));
+ 
diff --git a/sys-apps/systemd/files/242-socket-util-flush-accept.patch b/sys-apps/systemd/files/242-socket-util-flush-accept.patch
new file mode 100644
index 000000000000..4849c4c0789e
--- /dev/null
+++ b/sys-apps/systemd/files/242-socket-util-flush-accept.patch
@@ -0,0 +1,46 @@
+From f3d75364fbebf2ddb6393e54db5e10b6f6234e14 Mon Sep 17 00:00:00 2001
+From: Lennart Poettering <lennart@poettering.net>
+Date: Thu, 18 Apr 2019 15:13:54 +0200
+Subject: [PATCH] socket-util: make sure flush_accept() doesn't hang on
+ unexpected EOPNOTSUPP
+
+So apparently there are two reasons why accept() can return EOPNOTSUPP:
+because the socket is not a listening stream socket (or similar), or
+because the incoming TCP connection for some reason wasn't acceptable to
+the host. THe latter should be a transient error, as suggested on
+accept(2). The former however should be considered fatal for
+flush_accept(). Let's fix this by explicitly checking whether the socket
+is a listening socket beforehand.
+---
+ src/basic/socket-util.c | 17 +++++++++++++++--
+ 1 file changed, 15 insertions(+), 2 deletions(-)
+
+diff --git a/src/basic/socket-util.c b/src/basic/socket-util.c
+index 904bafb76f9..e787d53d8f4 100644
+--- a/src/basic/socket-util.c
++++ b/src/basic/socket-util.c
+@@ -1225,9 +1225,22 @@ int flush_accept(int fd) {
+                 .fd = fd,
+                 .events = POLLIN,
+         };
+-        int r;
++        int r, b;
++        socklen_t l = sizeof(b);
++
++        /* Similar to flush_fd() but flushes all incoming connection by accepting them and immediately
++         * closing them.  */
++
++        if (getsockopt(fd, SOL_SOCKET, SO_ACCEPTCONN, &b, &l) < 0)
++                return -errno;
+ 
+-        /* Similar to flush_fd() but flushes all incoming connection by accepting them and immediately closing them. */
++        assert(l == sizeof(b));
++        if (!b) /* Let's check if this is a socket accepting connections before calling accept(). That's
++                 * because accept4() can return EOPNOTSUPP in the fd we are called on is not a listening
++                 * socket, or in case the incoming TCP connection transiently triggered that (see accept(2)
++                 * man page for details). The latter case is a transient error we should continue looping
++                 * on. The former case however is fatal. */
++                return -ENOTTY;
+ 
+         for (;;) {
+                 int cfd;