On 14/06/06, Ingo Molnar <[email protected]> wrote:
* Catalin Marinas <[email protected]> wrote:
But it's not just about the amount of false negatives, but also about
the overhead of scanning. You are concentrated on embedded systems with
small RAM - but most of the testers will be running this with at last
1GB of RAM - which is _alot_ of memory to scan.
As Andi mentioned, it might not be a big issue since the page cache is
not scanned.
> The number of collisions would need to be investigated. On my system,
> there are 158 distinct sizeof values generated by container_of. Of
> this, 90 have at least two aliases (incoming pointer offsets). I'm not
> sure how many different structures are in the kernel but I can't find
> an easy (gcc magic) way to get a unique id for a type (apart from
> modifying all the container_of calls and add a 4th argument - maybe a
> string with the name of the type).
Looking at these collisions in more detail, from the above 90 only
about 40 are real collisions that introduce new aliases. The others
are container_of() usages on other members (task_struct has about 4
different aliases).
If the ID is string based then you dont even have to touch containr_of()
calls - just generate the typename string via the "#y" stringification
preprocessor directive, where 'y' is the second parameter of
container_of().
Since the linker seems to be smart enough to eliminate string
duplicates, a "const char *" can be used as a unique id (assuming that
the container_of is always called with the type name and not
"typeof").
there's another, much faster solution as well that assigns IDs
build-time for globally visible types: the __builtin_types_compatible_p
gcc extension to match the type against a global registry of types. I.e.
here's what i use in PREEMPT_RT:
[...]
it needs some thought, but this way it's quite possible to build-time
map types to IDs.
That's an interesting approach and it would work even with "typeof()"
constructs.
Anyway, in both the incoming and outgoing pointers case, the type
information needs to be associated with the allocated memory block.
This would mean that all the kmalloc/kmem_cache_alloc etc. calls in
the kernel have to be modified to pass the type information. Would
such a (big) patch be acceptable for the kernel? The sizeof is the
only information that could get close to type identification and is
passed to these functions, though it has its risks.
Is it also worth the effort? With the large number of platforms Linux
runs on, a leak would be spotted sooner or later.
--
Catalin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
