Re: 2.6.35-rc4-git3: Reported regressions from 2.6.34

[Eric Dumazet <eric.dumazet@gmail.com>]

Le jeudi 08 juillet 2010 à 21:34 -0700, David Miller a écrit :
> From: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Thu, 8 Jul 2010 18:34:25 -0700
> 
> > On Thu, Jul 8, 2010 at 4:33 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >>
> >> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16187
> >> Subject         : Carrier detection failed in dhcpcd when link is up
> >> Submitter       : Christian Casteyde <casteyde.christian@free.fr>
> >> Date            : 2010-06-12 15:15 (27 days old)
> >> First-Bad-Commit: http://git.kernel.org/linus/10708f37ae729baba9b67bd134c3720709d4ae62
> >> Handled-By      : Andrew Morton <akpm@linux-foundation.org>
> > 
> > David? This bisects to a networking commit. Doesn't look sensible, but
> > what do I know?
> 
> My suspicion is that dhcpd uses netlink to dump the info of the
> available links, and due to some bug gets confused with the new 64-bit
> statistic netlink attribute being there now.
> a second to have a look at this.

It could be a dhcpcd bug because of extended size of answer

According to strace, dhcpcd tries a recvmsg() call with
a 256 bytes buffer to hold answer.

Looking at current dhcpcd source, I confirm it cannot realloc its buffer

static int
get_netlink(int fd, int flags,
    int (*callback)(struct nlmsghdr *))
{
        char *buffer = NULL;
        ssize_t bytes;
        struct nlmsghdr *nlm;
        int r = -1;

        buffer = xzalloc(sizeof(char) * BUFFERLEN);
        for (;;) {
                bytes = recv(fd, buffer, BUFFERLEN, flags);
                if (bytes == -1) {
                        if (errno == EAGAIN) {
                                r = 0;
                                goto eexit;
                        }
                        if (errno == EINTR)
                                continue;
                        goto eexit;
                }


This program needs to fix this.