Received: by 10.223.164.202 with SMTP id h10csp1191096wrb; Tue, 7 Nov 2017 23:48:25 -0800 (PST) X-Google-Smtp-Source: ABhQp+QpLT10wz2rm71zaGlriEEa22if+oAt1Nhwnk28Vui4ue2SGGRKvAk8pO6Lk1swkt6KGKIU X-Received: by 10.99.122.92 with SMTP id j28mr1493687pgn.154.1510127305132; Tue, 07 Nov 2017 23:48:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510127305; cv=none; d=google.com; s=arc-20160816; b=TascO9FBKbgqOlmp0nclg9rp2ZXygsuLKb/pIiCiv5PIfRNtUNrRhVPk2Ou2qdrOoU 9xu1I2I/TbbfMIrw0DIeKCaXh6kpwMlME3DqTL/gCN7SKqIkiTn5I1FClXCCaiBsa0J4 49o+ElU5nvp9nsQRhEE3RNQABHFYbBIKDiAEpSJJd6JjylCJqRmB/UD3gDAnDT9oYSBn 9V2QaBhkIWAFvVIIedzPPOjzEgZK4qm3vvw6yAAS8IKkM+8/nwaALBsF0ijd3dGU9wIr ljyG94gqCoYT320ruw1iiML2kxWKZOTcXrPSZbpwzD5/7r0l5t8mp/SbjCzM8IFZ2Sg9 R4Dg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :references:in-reply-to:date:cc:to:from:subject:message-id :arc-authentication-results; bh=Q5YCQTKDiibBygG1odHsCVRqRBlILySJpSEyM+YWxbg=; b=COIfDTvIh59ubDMFydX5QPfq6L58bz3pcYbJNnuRjgSfQaZ+Re2sNSENTohjANteki C3mYA+BXrYh7UOKDmxAkeb2G3sPfDUfjrb8bDOI/sG22qW+mV/Bff2Tj5oS2NSs/7EO7 Ham1iOn9UNRRVA+Pl5gyTFCFKsTrW66tml43BTGyeFNGDwKkyg41cTQ9r9CVTI5Y8jGU vIKrdwW1NmvFE3bLxW2x4xT451pNLIaOJ9cqWv3lCVZS4UwiZ/coKaFG6QVUDz+WuUZM peAZQ26u0aTp9jv8Wn88oP/hwwRqGcgjNZ8+GGxqVjiqO3Tv14SjSf7HutjgrPKLua+P xfBw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d21si3265701pll.191.2017.11.07.23.48.12; Tue, 07 Nov 2017 23:48:25 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753247AbdKHFc0 (ORCPT + 91 others); Wed, 8 Nov 2017 00:32:26 -0500 Received: from mailgw01.mediatek.com ([210.61.82.183]:18510 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1752695AbdKHFcZ (ORCPT ); Wed, 8 Nov 2017 00:32:25 -0500 X-UUID: eb0804e6510d4d188f07dc2fd0cea5e3-20171108 Received: from mtkcas09.mediatek.inc [(172.21.101.178)] by mailgw01.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 1030725649; Wed, 08 Nov 2017 13:32:19 +0800 Received: from mtkcas08.mediatek.inc (172.21.101.126) by mtkmbs03n1.mediatek.inc (172.21.101.181) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 8 Nov 2017 13:32:17 +0800 Received: from [172.21.77.33] (172.21.77.33) by mtkcas08.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1210.3 via Frontend Transport; Wed, 8 Nov 2017 13:32:18 +0800 Message-ID: <1510119138.17435.19.camel@mtkswgap22> Subject: Re: [PATCH] slub: Fix sysfs duplicate filename creation when slub_debug=O From: Miles Chen To: Christopher Lameter CC: Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , , , , Date: Wed, 8 Nov 2017 13:32:18 +0800 In-Reply-To: References: <1510023934-17517-1-git-send-email-miles.chen@mediatek.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-MTK: N Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2017-11-07 at 09:22 -0600, Christopher Lameter wrote: > On Tue, 7 Nov 2017, miles.chen@mediatek.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. yes > > > 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 aliasing failed because find_mergeable() returns if (flags & SLAB_NEVER_MERGE) is true. So we do not go to search for alias caches. __kmem_cache_alias() find_mergeable() kmem_cache_flags() --> setup flag by the slub_debug if (flags & SLAB_NEVER_MERGE) return NULL; ... search alias logic... The flags maybe changed if disable_higher_order_debug=1. So the unmergeable cache becomes mergeable later. > > The clearing of the DEBUG_METADATA_FLAGS looks ok to me. kmem_cache_alias > should do the same right? > Yes, I think clearing DEBUG_METADATA flags in kmem_cache_alias is another solution for this issue. We will need to do calculate_sizes() by using original flags and compare the order of s->size and s->object_size when disable_higher_order_debug=1. From 1583470371938714970@xxx Wed Nov 08 04:23:44 +0000 2017 X-GM-THRID: 1583422685647743875 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread