On Mon, Apr 8, 2019 at 7:14 PM Kees Cook <keescook@xxxxxxxxxxxx> wrote: > > On Mon, Apr 8, 2019 at 9:43 AM Laura Abbott <labbott@xxxxxxxxxx> wrote: > > I've looked at doing something similar in the past (failing to find > > the thread this morning...) and while this will work, it has pretty > > serious performance issues. It's not actually the poisoning which > > is expensive but that turning on debugging removes the cpu slab > > which has significant performance penalties. > > > > I'd rather go back to the proposal of just poisoning the slab > > at alloc/free without using SLAB_POISON. > > I still agree this would make the most sense. Fundamentally it's not a > debugging feature. Wasn't it you who suggested using SLAB_POISON in the first round of comments? :) I actually have a working implementation that piggybacks on existing __GFP_ZERO code to initialize page_alloc() and SLUB allocations: https://github.com/google/kmsan/commit/4907af529ad525378a0728435c96d3812f71e594 https://github.com/google/kmsan/commit/69618a9668bcf27700cc5da42eebf8ab50d1f56a I'd better cook a patch based on that. There's also some overhead when allocations are initialized twice (in page_alloc() and kmalloc()) or thrice (page_alloc(), kmalloc() and e.g. sock_alloc_send_pskb()) We can introduce another GFP flag explicitly telling the allocator to not initialize the memory chunk if we know it'll be initialized by a higher level allocator (something along the lines of https://github.com/google/kmsan/commit/4fc8cff79d868c29688c8a4186e504fda362f6fd) > -- > Kees Cook -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg