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: santi...@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
