lkml.org 
[lkml]   [2018]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)
    On Tue, 31 Jul 2018, Andrey Ryabinin wrote:

    > Guys, it seems that we have a lot of code using SLAB_TYPESAFE_BY_RCU cache without constructor.
    > I think it's nearly impossible to use that combination without having bugs.
    > It's either you don't really need the SLAB_TYPESAFE_BY_RCU, or you need to have a constructor in kmem_cache.
    >
    > Could you guys, please, verify your code if it's really need SLAB_TYPSAFE or constructor?
    >
    > E.g. the netlink code look extremely suspicious:
    >
    > /*
    > * Do not use kmem_cache_zalloc(), as this cache uses
    > * SLAB_TYPESAFE_BY_RCU.
    > */
    > ct = kmem_cache_alloc(nf_conntrack_cachep, gfp);
    > if (ct == NULL)
    > goto out;
    >
    > spin_lock_init(&ct->lock);
    >
    > If nf_conntrack_cachep objects really used in rcu typesafe manner, than 'ct' returned by kmem_cache_alloc might still be
    > in use by another cpu. So we just reinitialize spin_lock used by someone else?

    ct may still be read by another cpu in a RCU section but the object was
    freed elsewhere so no other processor may modify the object.

    The lock must have been released before freeing the slab object and thus
    the initialization of the spinlock is unnecessary if it was
    initialized in ctor.

    If there is refcounting going on then why use SLAB_TYPESAFE_BY_RCU?

    \
     
     \ /
      Last update: 2018-07-31 19:37    [W:4.200 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site