Open DreamerKMP opened 2 years ago
I can reproduce the issue in my code using netlink.RouteSubscribeWithOptions()
@DreamerKMP @stv0g please feel free to open a pull request with your proposed fix
The netlink(7) man-page describes the purpose of nl_pid as follows:
nl_pid
is the unicast address of netlink socket. It's always 0 if the destination is in the kernel. For a user-space process,nl_pid
is usually the PID of the process owning the destination socket. However,nl_pid
identifies a netlink socket, not a process. If a process owns several netlink sockets, then nl_pid can be equal to the process ID only for at most one socket. There are two ways to assignnl_pid
to a netlink socket. If the application setsnl_pid
before calling bind(2), then it is up to the application to make sure that nl_pid is unique. If the application sets it to 0, the kernel takes care of assigning it. The kernel assigns the process ID to the first netlink socket the process opens and assigns a uniquenl_pid
to every netlink socket that the process subsequently creates.
The check occurs at several places:
Did this issue solved? And whether the ProcEvent which 'fromPid != nl.PidKernel' can be used for process detection?
Hi!
I recently ran into a problem when calling the
netlink.NeighSubscribeWithOptions()
andnetlink.LinkSubscribeWithOptions()
functions from multiple go-routines.The code causing the problem is below.
Actually I checked the message through
strace
.If you look at the message, you can see that
nl_pid
has a different value (id
of another thread) than the value ofPidKernel
. So the preceding code caused the error.I think that code is unnecessary. Please review this.