[lkml]   [2018]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 3/4] mm: Add free()

> > And sure, your free() implementation obviously also has that property,
> > but I'm worried that they might one day decide to warn about the
> > prototype mismatch (actually, I'm surprised it doesn't warn now, given
> > that it obviously pretends to know what free() function I'm calling...),
> > or make some crazy optimization that will break stuff in very subtle ways.
> >
> > Also, we probably don't want people starting to use free() (or whatever
> > name is chosen) if they do know the kind of memory they're freeing?
> > Maybe it should not be advertised that widely (i.e., in kernel.h).
> All that you've said I see as an advantage, not a disadvantage.
> Maybe I should change the prototype to match the userspace
> free(), although gcc is deliberately lax about the constness of
> function arguments when determining compatibility with builtins.
> See match_builtin_function_types() if you're really curious.
> gcc already does some nice optimisations around free(). For example, it
> can eliminate dead stores:

Are we comfortable with that optimalization for kernel?

us: "Hey, let's remove those encryption keys before freeing memory."
gcc: :-).

us: "Hey, we want to erase lock magic values not to cause confusion
gcc: "I like confusion!"

Yes, these probably can be fixed by strategic "volatile" and/or
barriers, but...
(cesky, pictures)
[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2018-04-03 10:52    [W:0.062 / U:0.468 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site