* Catalin Marinas <catalin.marinas@xxxxxxxxx> wrote:
> Do you need these fixes to avoid a compiler error? If yes, this is
> caused by a bug in gcc-4.x. The kmemleak container_of macro has
> protection for non-constant offsets passed to container_of but the
> faulty gcc always returns true for builtin_contant_p, even when this
> is not the case. Previous versions (3.4) or one of the latest 4.x gcc
> don't have this bug.
correct, i needed it for gcc 4.0.2. If you want this feature upstream,
this has to be solved - no way are we going to phase out portions of
gcc4. It's not hard as you can see it from my patch, non-static
container_of is very rare. We do alot of other hackery to keep older
compilers alive, and we only drop compiler support if some important
feature really, really needs new gcc and a sane workaround is not
possible.
> In the -rt kernel, is there any protection against a re-entrant
> __cache_free (via cache_flusharray -> free_block -> slab_destroy) or
> this is not needed?
the problem on -rt is the per-CPU slab buffer handling. In vanilla they
are handled with irqs off/on - but inside is an unbound algorithm so for
-rt i converted the local_irq_disable() logic to per-CPU locks. So this
is an -rt only problem.
hm, even on vanilla you might run into problems in slab_destroy(), there
we hold the l3 lock.
> There are also the memleak_object structures that need to be
> allocated/freed. To avoid any locking dependencies, I ended up
> delaying the memleak_object structures freeing in an RCU manner. It
> might work if I do the same with the hash nodes.
yeah, delayed RCU freeing might work better.