This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Unexpected netlink response of size <number> on descriptor <number>
- From: Florian Weimer <fweimer at redhat dot com>
- To: Abhi Arora <engr dot abhiarora at gmail dot com>
- Cc: libc-help at sourceware dot org
- Date: Fri, 20 Dec 2019 10:32:08 +0100
- Subject: Re: Unexpected netlink response of size <number> on descriptor <number>
- References: <CADqM=-y2bCb7d+FZ4JGJjC3FVcT-Tpx5uvYVMggr0B+d+B8kDw@mail.gmail.com> <87tv5wjhf3.fsf@oldenburg2.str.redhat.com> <CADqM=-xEhz4B8JtpiZk_C4Netynim-K9HKFVXfzJ8hYhnkKLqg@mail.gmail.com>
* Abhi Arora:
> Thank you for your answer. However, I want to understand this
> "descriptor race". You mean if any application is also using the
> netlink descriptor along with getaddrinfo() ?.
>
> I think what you mean is "If my application opens and closes a netlink
> socket descriptor (say it is 5) and even after closing it, it reuses
> that file descriptor for further operations. However, in the meantime,
> getaddrinfo() was called and it opens a netlink descriptor. Since,
> kernel returns lowest free file descriptor number, it may return 5.
> Now, two parts of an application are using the same file descriptor
> and hence, data send by application could be received by netlink
> descriptor opened by getaddrinfo() or vice-verse. Hence, I have
> received that error message "Uxpected error 9 on netlink descriptor
> 6" ".
I think you got it pretty much correct.
The race looks typically like this:
application closes descriptor 5
glibc opens netlink descriptor 5
application closes descriptor 5 (again)
application opens some other file or socket, receives descriptor 5
glibc tries to use descriptor 5
And at the last step, glibc detects that the descriptor is no longer a
netlink descriptor, and aborts the process.
Thanks,
Florian