Comment # 3 on bug 1198877 from Jan Engelhardt

I'd ask bug 1198817 to run strace just to confirm it's the same issue.

I have IPv6 with frequent address changes (sysctl as follows):

net.ipv6.conf.all.use_tempaddr=2
net.ipv6.conf.all.router_solicitation_interval=60
net.ipv6.conf.all.max_addresses=1000
net.ipv6.conf.all.temp_prefered_lft=900
net.ipv6.conf.eth0.max_addresses=1000
net.ipv6.conf.eth0.temp_prefered_lft=900

# ip mon route
Deleted local xxxx:xxxx:xxxx:34ec:2ac2:f742:4e62:a58d dev eth0 table local
proto kernel metric 0 pref medium
local xxxx:xxxx:xxxx:34ec:670a:f284:d22a:b1dc dev eth0 table local proto kernel
metric 0 pref medium
(and this about every 15 minutes)

Not sure how the POLLERR comes to be. There really is just one place in the
Linux kernel that seems to bear any relevancey,
(kernel)/net/core/datagram.c:datagram_poll::

        /* exceptional events? */
        if (sk->sk_err || !skb_queue_empty(&sk->sk_error_queue))
                mask |= POLLERR;

This itself is fed from:

net/netlink/af_netlink.c:               sk->sk_err = ENOBUFS;
net/netlink/af_netlink.c:       sk->sk_err = p->code;
net/netlink/af_netlink.c:                       sk->sk_err = ENOBUFS;

This goes to show that Netlink _can_ cause POLLERR itself and that POLLERR is
not necesarily a result of, for example, erroneously calling poll() on a closed
file descriptor.