svn commit: r334104 - in head/sys: netinet sys

[Matthew Macy]

I've re-edited that code twice by request by others. I will amend it
again at some point to reflect this viewpoint.

On Sat, May 26, 2018 at 12:44 PM, Eric van Gyzen <eric at vangyzen.net> wrote:
> On 05/23/2018 23:47, Gleb Smirnoff wrote:
>>
>> On Thu, May 24, 2018 at 06:44:20AM +0200, Mateusz Guzik wrote:
>> M> I fundamentally disagree with this part.
>> M>
>> M> If a known value of a given field is needed for assertion purposes, you
>> M> can add (possibly conditional) code setting this specific value. It
>> M> probably should not be zero if it can be helped.
>> M>
>> M> Conditional zeroing of the *whole* struct depending on invariants will
>> M> *hide* uninitialized memory read bugs - production kernel will have
>> M> whatever it happens to find, while *debug* kernel will guarantee to
>> M> have all the values zeroed. In fact the flag actively combats
>> redzoning.
>> M> if the resulting allocation is zeroed, poisoning is actively neutered.
>> M> But only if debug is enabled.
>> M>
>> M> That said, I find the change harmful.
>>
>> +1 on fundamentally disagree with M_ZERO_INVARIANTS. It makes the
>> INVARIANTS-enabled kernels to crash _later_ than production kernels,
>> since instead of uma_junk it places clean zeroes.
>
>
> Matt,
>
> Mateusz and Gleb raise very good points.  This operates contrary to the
> whole idea of INVARIANTS.  Please revisit this.
>
> Eric