Re: kern/54150: COMPAT_50 vs NET_RT_IFLIST

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR kern/54150; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/54150: COMPAT_50 vs NET_RT_IFLIST
Date: Fri, 03 May 2019 10:56:36 +0700

 Ignore most of my last message ... or treat it as what happens
 when running on NetBSD 8 (which I have not tested, but is probably
 close).   Since this was supposed to be the same from pre NetBSD-8
 through HEAD, I was testing on my laptop which is running a kernel
 from just before PaulG's module merge (January 6 or something).
 
 With that, what I described is approx what happens, I think.
 
 After the merge, the sysctl messages are all the same version - but
 the wrong one (a -5 binary generates RTM_VERSION 4 messages, and
 should be 3).   I have a hack fix for that, after which ifconfig -l
 from -5 core dumps (aborts) which is the same as my test program
 (new sources, doing the NetBSD 5 sysctl, so I can see what is
 actually being returned).   (The abort() tells me that at least
 the getifaddrs() code is not simply ignoring everything returned,
 which is what happens when the version is wrong).
 
 The abort() comes from in getifaddrs() from the line ...
 
                 case RTM_NEWADDR:
                         ifam = (struct ifa_msghdr *)(void *)rtm;
                         if (idx && ifam->ifam_index != idx)
                                 abort();        /* this cannot happen */
 
 I have no idea what the comment is about, ifam->ifam_index comes from
 the sysctl result, idx is calculated in getifaddrs() - what it should
 be saying is "this should not happen" - as obviously it can, if the
 kernel is returning messages in a form that getifaddrs() is not
 expecting.   An abort for that, rather than just a failure is a little
 severe, I think.
 
 Note that the second copy of almost the same code should be OK, as when
 that runs, the first one must have already passed, and so there, "cannot
 happen" really should be true (absent hardware or compiler issues.)
 
 Still looking, but clearly something is not right about the message
 formats (it does not appear to be an "O" counting error ... but who
 knows).
 
 kre