In message <Pine.LNX.4.44.0209240731060.8824-100000@localhost.localdomain> you
write:
> - kmalloc(size, flags)/gfp(order, flags) argument ordering. A few months
> ago i wasted two days on such a bug - since 'size' was very small
> usually, it never showed up that the allocated buffer was short, until
> some rare load-test increased the 'size'.
>
> we should do something about these. list_add() is hard, while we could
> introduce a separate type for list heads, there are some valid uses of
> non-head list_add(). But perhaps those could be separated out.
>
> handling most of the gfp() mixups should be a bit easier, perhaps by
> detecting invalid flags in the inline section, which is optimized away at
> runtime in like 95% of the cases?
I had a gcc patch which made enum typing strict for C
(-Wstrict-enums), which was designed for the GFP_xxx case and things
like it (you make them enums). It was against 2.95.2, RSN I should
update it, and (as Tridge suggested) make it an __attribute__.
For runtime checks (which are never as good) you could change the GFP_
defined to set the high bit.
Rusty.
-- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Sep 30 2002 - 22:00:17 EST