logging via udp
Ondrej Zajicek
santiago at crfreenet.org
Wed Dec 13 17:02:34 CET 2023
On Wed, Dec 13, 2023 at 02:59:47PM +0100, Alexander Zubkov wrote:
> > > And could you, please, also explain another moment:
> > > https://gitlab.nic.cz/labs/bird/-/commit/2c7555cf2ac8439713dd9148b348128c57222a38#bc490dc797778621d2345fabe1fb0b59fce18264_141_179
> > > Here your free the sk resource. Maybe this is done exactly because of
> > > the io loop list, but I cannot find how sk_free() would remove the
> > > socket from sock_list. It seems to me it would still refer the socket
> > > after it is freed.
> >
> > sk_free() calls rem_node(&s->n) for non-SKF_THREAD sockets, so it would
> > remove it from sock_list anyway.
>
> As it is SKF_THREAD, it is not relevant yet. But I see here fd is set
> to -1 before rfree():
> https://gitlab.nic.cz/labs/bird/-/commit/2c7555cf2ac8439713dd9148b348128c57222a38#bc490dc797778621d2345fabe1fb0b59fce18264_141_179
> And sk_free() will not call rem_node() in this case:
> https://gitlab.nic.cz/labs/bird/-/blob/2c7555cf2ac8439713dd9148b348128c57222a38/sysdep/unix/io.c#L834
> I worry it can lead to a hidden error in the future.
You are right, it would be better to have some sk invalidationg function
that would set fd to -1 and unlink it, instead of doing that manually.
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
"To err is human -- to blame it on a computer is even more so."
More information about the Bird-users
mailing list