On Wed, 4 Mar 2020, David Rientjes wrote: > I'm not sure how dependent the CONFIG_SLUB_DEBUG users are on being able > to modify these are runtime (they've been around for 12+ years) but I > agree that it seems particularly dangerous. The order of each individual slab page is stored in struct page. That is why every slub slab page can have a different order. This enabled fallback to order 0 allocations and also allows a dynamic configuration of the order at runtime. > The slub_debug kernel command line options are already pretty > comprehensive as described by Documentation/vm/slub.rst. I *think* these > tunables were primarily introduced for kernel debugging and not general > purpose, perhaps with the exception of "order". What do you mean by "general purpose? Certainly the allocator should not blow up when forcing zero order allocations. > So I think we may be able to fix "order" with a combination of my patch as > well as a fix to the freelist randomization and that the others should > likely be made read only. Hmmm. races increases as more metadata is added that is depending on the size of the slab page and the number of objects in it.
