Subject: Re: kern/1515 [Re: PR-7148 (causes kernel panic)]
To: None <email@example.com>
From: Christos Zoulas <firstname.lastname@example.org>
Date: 11/07/1999 20:57:35
In article <19991107194245.A794@antioche.eu.org>,
Manuel Bouyer <email@example.com> wrote:
>working on the RTM_IFINFO message I ran into a problem:
>now the kernel will panic in rt_msg1() when trying to send a RTM_IFINFO
>message, because the size of the message is greater than MHLEN when stats
>are 64bit counters. On alpha, MSIZE is 256, on all others 128 (which means
>sparc64 is probably brocken at this time :).
>I can see 3 ways of solving this:
>1) remove the stats from the RTM_IFINFO message. I wonder if any program
> use this part of the message but this breaks compatibility.
>2) bump MSIZE to 256 on all port. I don't know what impact this will have
> on memory usage.
>3) Define a new type (ifstat_t) which can be either 32 or 64 bit, defined
> per port in a machine-dependant header (which one ? machine/types.h ?).
> So we could keep 32 bit counters and MSIZE to 128 on machines with slow CPU
> or low memory and 64bit otherwise.
>1) is probably evil. I would go for 2), given that even a vax can
>stay up enouth to overflow 32 bit counters ... I think a vax is able to push
>out 1G or data per week, isn't it ? This makes the counter overflow
>after 4 weeks.
Can't you just add another mbuf to the chain? Maybe using M_PREPEND?