lkml.org 
[lkml]   [2019]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v4] kmemleak: survive in a low-memory situation
    On Thu, Mar 28, 2019 at 08:05:31AM +0200, Pekka Enberg wrote:
    > On 27/03/2019 2.59, Qian Cai wrote:
    > > Unless there is a brave soul to reimplement the kmemleak to embed it's
    > > metadata into the tracked memory itself in a foreseeable future, this
    > > provides a good balance between enabling kmemleak in a low-memory
    > > situation and not introducing too much hackiness into the existing
    > > code for now.
    >
    > Unfortunately I am not that brave soul, but I'm wondering what the
    > complication here is? It shouldn't be too hard to teach calculate_sizes() in
    > SLUB about a new SLAB_KMEMLEAK flag that reserves spaces for the metadata.

    I don't think it's the calculate_sizes() that's the hard part. The way
    kmemleak is designed assumes that the metadata has a longer lifespan
    than the slab object it is tracking (and refcounted via
    get_object/put_object()). We'd have to replace some of the
    rcu_read_(un)lock() regions with a full kmemleak_lock together with a
    few more tweaks to allow the release of kmemleak_lock during memory
    scanning (which can take minutes; so it needs to be safe w.r.t. metadata
    freeing, currently relying on a deferred RCU freeing).

    Anyway, I think it is possible, just not straight forward.

    --
    Catalin

    \
     
     \ /
      Last update: 2019-03-28 11:31    [W:3.983 / U:0.240 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site