Re: New class of receive error

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

    Date:        Sun, 13 May 2018 15:39:07 +0100
    From:        Roy Marples <roy%marples.name@localhost>
    Message-ID:  <88e323a6-c0ac-b870-ab38-7a34bde6ac2b%marples.name@localhost>

  |  Comments that have existed in our code as far back as I've 
  | checked seem to agree with stuff like this:
  | /* XXX notify userland of overflow */

Where exactly is that string in the NetBSD kernel, I have looked and
cannot find anything that even comes close.

Doing 'grep -i' (so I am not missing anything with capitals) the only
instance I can find of 'XXX notify' (with any amount of any kind of
white space where that shows a single space) is in dev./ata/wd.c
(and I don't think that's related).

The only instance of "notify userland" is in arch/x86/x86/identcpu.c
which I also don't think is related.

So which of "our code' is it that has that comment?

  | Here's a list from a trivial 
  | search and basic examination:
  | 	rarpd, racoon, ifwatchd, route (monitor), rtadvd

That's all routing socket.   I don't even need to read the code
to know that rtadvd doesn't care - but aside from that, those
might potentially benefit.  The routing socket really is special.
But they can only benefit of their code is changed, and if their
code changes to gain that benefit, they could easily have a
"turn on" sockioctl() added at the same time.   Until then all
you have done is given them yet another error they can receive
and have no idea what to do with.

  | I, for one, would be interested in knowing that the logging mechanism is 
  | failing.

When it is syslog() that would be better performed at the sender.

Aside from that, knowing (just for general information, rather than
for any attempt to recover in a particular case) this is the kind of
info that netstat -m should provide.   That could provide info that
something is busier than the system is designed to handle, and
bigger buffers might be useful (on a particular system).

  | We don't know the importance of the message that would 
  | otherwise have been silently discarded. But at least we now know, so we 
  | can do something about it.

Do what?

  | > If you want complete routing information use synchronous queries
  | > and use routing socket messages only as an optimization.
  |
  | I believe that's what I've done?

Yes, I agree, no-one is doubting the code in dhcpcd - just that you have
also inflicted this on every other application in the system, without fixing
them to handle it (all that has happened is an increase in the buffer
sizes so that it is less likely to happen - ie: an attempt to hide the issue
so no-one notices.)

kre