inetd bug
Cathey, Jim
jcathey at ciena.com
Wed Nov 5 17:47:50 UTC 2008
On the face of it I think this fix is inadequate,
given that "maxsock + 1" is used in the select().
With no services, should select not have a 0 as the
first argument, thus requiring maxsock to be -1 and
not 0? All the problems fell out of that value.
-- Jim
-----Original Message-----
From: Denys Vlasenko [mailto:vda.linux at googlemail.com]
Sent: Wednesday, November 05, 2008 3:37 AM
To: wharms at bfs.de
Cc: Cathey, Jim; busybox at busybox.net
Subject: Re: inetd bug
> Cathey, Jim schrieb:
>> We've been using BB, and found that when we had an /etc/inetd.conf
>> file with only one service in it, said service being commented in
>> and out as it was enabled/disabled by the system (along with a HUP
>> to inetd), that the lone service could not re-enable. I tracked it
>> down to a bug where the maxsock variable wasn't being used correctly.
Can you explain where exactly that failed? Form what I can see,
the only erroneous place is this one (fix is shown too):
static void recalculate_maxsock(void)
{
int fd = 0;
+ maxsock = 0;
while (fd <= prev_maxsock) {
if (FD_ISSET(fd, &allsock))
maxsock = fd;
Basically, if there are no services at all, maxsock was not updated
and stayed -1, the rest of code was not expecting that can ever happen
after recalculate_maxsock().
Am I right in my analysis or are there other places where code is wrong?
IOW, does the above fix work for you?
--
vda
More information about the busybox
mailing list