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 <e...@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 _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
