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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.02.1503252157330.6657@file01.intranet.prod.int.rdu2.redhat.com>
Date:	Wed, 25 Mar 2015 22:18:48 -0400 (EDT)
From:	Mikulas Patocka <mpatocka@...hat.com>
To:	David Rientjes <rientjes@...gle.com>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Dave Kleikamp <shaggy@...nel.org>,
	Christoph Hellwig <hch@....de>,
	Sebastian Ott <sebott@...ux.vnet.ibm.com>,
	Catalin Marinas <catalin.marinas@....com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	jfs-discussion@...ts.sourceforge.net
Subject: Re: [patch 1/4] fs, jfs: remove slab object constructor



On Tue, 24 Mar 2015, David Rientjes wrote:

> Mempools based on slab caches with object constructors are risky because
> element allocation can happen either from the slab cache itself, meaning
> the constructor is properly called before returning, or from the mempool
> reserve pool, meaning the constructor is not called before returning,
> depending on the allocation context.

I don't think there is any problem. If the allocation is hapenning from 
the slab cache, the constructor is called from the slab sybsystem.

If the allocation is hapenning from the mempool reserve, the constructor 
was called in the past (when the mempool reserve was refilled from the 
cache). So, in both cases, the object allocated frmo the mempool is 
constructed.

Mikulas

> For this reason, we should disallow creating mempools based on slab
> caches that have object constructors.  Callers of mempool_alloc() will
> be responsible for properly initializing the returned element.
> 
> Then, it doesn't matter if the element came from the slab cache or the
> mempool reserved pool.
> 
> The only occurrence of a mempool being based on a slab cache with an
> object constructor in the tree is in fs/jfs/jfs_metapage.c.  Remove it
> and properly initialize the element in alloc_metapage().
> 
> At the same time, META_free is never used, so remove it as well.
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ