Various data structures are used to implement the slab allocator as described above. Although this does not appear to be difficult, the code is not always easy to read or understand. This is because many memory areas need to be manipulated using pointer arithmetic and type-casting — not necessarily one of the areas of C famed for its clarity. The code is also pervaded with pre-processor statements because the slab system features numerous debugging options. 31 Some of these are listed below:

□ Red Zoning — An additional memory area filled with a known byte pattern is placed at the start and end of each object. If this pattern is overwritten, programmers will note when analyzing kernel memory that their code accesses memory areas that don't belong to them.

□ Object Poisoning — Objects are filled with a predefined pattern when a slab is created and freed. If it is noted at object allocation that this pattern is changed, programmers know that unauthorized access has already taken place.

For the sake of simplicity and to focus attention on the big picture rather than minor details, let's restrict our description below to a ''pure'' slab allocator that doesn't make use of the above options.

31The CONFIG_DEBUG_SLAB configuration option must be set at compilation time to enable debugging. However, this significantly slows allocator performance.

Continue reading here: Data Structures

Was this article helpful?

0 0