[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/54150: COMPAT_50 vs NET_RT_IFLIST
The following reply was made to PR kern/54150; it has been noted by GNATS.
From: Robert Elz <kre%munnari.OZ.AU@localhost>
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 ...
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
Main Index |
Thread Index |