Re: Proposal: kmem_valloc [was: Re: raspberry pi panic 7.0_BETA after install fs resize]

[Michael van Elst <mlelstv%serpens.de@localhost>]

On Sat, Nov 08, 2014 at 07:46:08PM +0100, Maxime Villard wrote:
> Le 08/11/2014 19:08, Michael van Elst a écrit :
> >As a side effect, it removed the debugging features of malloc/free.
> 
> As well as it allowed many bugs.

I doubt that it allowed many bugs. It made code slightly more complex,
but it also made people look at what the code does.

For the most recent issue in ffs, it might even have exposed a bug
as the change to the fs structure apparently did not cause a
re-allocation of the csum structure, which is the real problem.
Fixing only the de-allocation just hides that bug.


> >>That's what motivates my proposal: creating kmem_valloc and kmem_vfree,
> >>to definitely get rid of malloc, and have another set of functions
> >>that can perform allocations/deallocations without needing a size
> >>argument. The 'v' stands for "variable".
> >
> >Looks like the worst of both worlds.
> >
> 
> Could you elaborate a bit?

kmem_alloc/kmem_free
- almost irrelevant optimization
- requires tracking of allocations
+ could validate alloc vs. free size

malloc/free
- some overhead for tracking + tagging allocations
+ simpler code for fixed data structures
-/+ not really a constructor/deconstructor
+ tagging allocations helps debugging (*)

(*) Yes, I know that this is only a dummy parameter now.

Your suggestion would
- add another interface
- add some overhead
- be used for a few fringe cases, unless it replaces kmem_alloc/kmem_free
-/+ would not help debugging like malloc/free


You can see that I consider the malloc/free API better than
kmem_alloc/kmem_free. But going half-a-step to create yet
another interface isn't the right thing.



Greetings,
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."