[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1711070916480.18776@nuc-kabylake>
Date: Tue, 7 Nov 2017 09:22:18 -0600 (CST)
From: Christopher Lameter <cl@...ux.com>
To: Miles Chen <miles.chen@...iatek.com>
cc: Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
wsd_upstream@...iatek.com, linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH] slub: Fix sysfs duplicate filename creation when
slub_debug=O
On Tue, 7 Nov 2017, miles.chen@...iatek.com wrote:
> When slub_debug=O is set. It is possible to clear debug flags
> for an "unmergeable" slab cache in kmem_cache_open().
> It makes the "unmergeable" cache became "mergeable" in sysfs_slab_add().
Right but that is only if disable_higher_order_debug is set.
> These caches will generate their "unique IDs" by create_unique_id(),
> but it is possible to create identical unique IDs. In my experiment,
> sgpool-128, names_cache, biovec-256 generate the same ID ":Ft-0004096"
> and the kernel reports "sysfs: cannot create duplicate filename
> '/kernel/slab/:Ft-0004096'".
Ok then the aliasing failed for some reason. The creation of the unique id
and the alias detection needs to be in sync otherwise duplicate filenames
are created. What is the difference there?
The clearing of the DEBUG_METADATA_FLAGS looks ok to me. kmem_cache_alias
should do the same right?
Powered by blists - more mailing lists