lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 12 Dec 2008 14:27:45 +0000 From: Catalin Marinas <catalin.marinas@....com> To: Pekka Enberg <penberg@...helsinki.fi> Cc: linux-kernel@...r.kernel.org Subject: Re: [PATCH 03/15] kmemleak: Add the slab memory allocation/freeing hooks On Thu, 2008-12-11 at 23:22 +0200, Pekka Enberg wrote: > Catalin Marinas wrote: > > @@ -2610,6 +2611,13 @@ static struct slab *alloc_slabmgmt(struct kmem_cache *cachep, void *objp, > > /* Slab management obj is off-slab. */ > > slabp = kmem_cache_alloc_node(cachep->slabp_cache, > > local_flags & ~GFP_THISNODE, nodeid); > > + /* > > + * Only scan the list member to avoid false negatives > > + * (especially caused by the s_mem pointer) > > + */ > > Heh, I run into this part again and as I have a long term memory of a > goldfish I had to look up the discussion we had. So may I suggest you > change the comment to: > > /* > * If the first object in the slab is leaked (it's allocated but no > * one has a reference to it), we want to make sure kmemleak does not > * treat the ->s_mem pointer as a reference to the object. Otherwise > * we will not report the leak. > */ OK, thanks. It's more verbose but it makes it pretty clear. > > + memleak_scan_area(slabp, offsetof(struct slab, list), > > + sizeof(struct list_head), > > + local_flags & ~GFP_THISNODE); > > if (!slabp) > > return NULL; > > } else { > > @@ -3195,6 +3203,8 @@ static inline void *____cache_alloc(struct kmem_cache *cachep, gfp_t flags) > > STATS_INC_ALLOCMISS(cachep); > > objp = cache_alloc_refill(cachep, flags); > > } > > + /* avoid false negatives */ > > + memleak_erase(&ac->entry[ac->avail]); > > For this, maybe something like this: > > /* > * To avoid a false negative, if an object that is in one of the > * per-CPU caches is leaked, we need to make sure kmemleak doesn't > * treat the array pointers as a reference to the object. > */ OK. > > return objp; > > } > > > > Do you take care of the per-node lists as well? I can't figure out what other location should be erased. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists