On Tue, Dec 13, 2022 at 12:33:03AM +0100, Michael Knudsen wrote: > We can detect this class of error by redefining the flags to > use the high bits instead of the low ones. This way the malloc() > KMEMSTAT value check triggers because 0x10000000 is greater than > the maximum type value. > > I tested the following, and it boots fine, and when I moved > M_ZERO to the type field in acpibtn the allocation panicked. > > (Of course, having different prefixes for type and flags would > help but that is another matter.)
In general I think finding such errors quickly would be nice. Is there a way to make this a compile time error? I guess that requires some ugly macro magic. Also depending on KMEMSTAT to trigger the error seems not the best design. > Index: sys/malloc.h > =================================================================== > RCS file: /cvs/src/sys/sys/malloc.h,v > retrieving revision 1.122 > diff -u -p -r1.122 malloc.h > --- sys/malloc.h 3 Feb 2022 17:18:22 -0000 1.122 > +++ sys/malloc.h 12 Dec 2022 23:24:23 -0000 > @@ -53,11 +53,13 @@ > > /* > * flags to malloc > + * Uses high bits to trigger 'type' limit check > + * if misused. > */ > -#define M_WAITOK 0x0001 > -#define M_NOWAIT 0x0002 > -#define M_CANFAIL 0x0004 > -#define M_ZERO 0x0008 > +#define M_WAITOK 0x10000000 > +#define M_NOWAIT 0x20000000 > +#define M_CANFAIL 0x40000000 > +#define M_ZERO 0x80000000 > > /* > * Types of memory to be allocated > > -- > Rumour is information distilled so finely that it can filter > through anything. > -- (Terry Pratchett, Feet of Clay) > -- :wq Claudio
