From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 031E2C43334 for ; Wed, 8 Jun 2022 12:23:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 35B0E6B00A2; Wed, 8 Jun 2022 08:23:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 30B008D0021; Wed, 8 Jun 2022 08:23:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1D12B6B00A4; Wed, 8 Jun 2022 08:23:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 0A0EB6B00A2 for ; Wed, 8 Jun 2022 08:23:49 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id C16AD35684 for ; Wed, 8 Jun 2022 12:23:48 +0000 (UTC) X-FDA: 79554984936.11.E4C87AB Received: from gentwo.de (gentwo.de [161.97.139.209]) by imf07.hostedemail.com (Postfix) with ESMTP id 2726040004 for ; Wed, 8 Jun 2022 12:23:48 +0000 (UTC) Received: by gentwo.de (Postfix, from userid 1001) id C9AE5B0029F; Wed, 8 Jun 2022 14:23:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gentwo.de; s=default; t=1654691025; bh=Dqp3UNZj24AihPQbByxI29k6/zx3njIxMdo6IGXPy4A=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ujq/NsBN4f0T6gznoVp6PlGaQMBDlQVXP0U56PC162ToLv7txeNrHW2UW73VPeUT1 ne7iMf0eYih60b1+yMn/0VP8aTcN2ELBvVUrsFUiIk/hY6qzZDGJzuijhBdybh4cRd 6/L8sReQ6x+ekTtn+OceroBP+uOfCIVDM4TQvjhtyZrhsp87MqSyQYhDyr5rNRijko WHzO7LZYFHlSP8rXs91vP9MPFR09gQXLH+lMpPqlRZIWnsU4q4eyFEgWPltUgtzL8R KTabq93Yc+y4Bik++2awsEha6MLGP0N9rQZov/NbLU7B2Kyi4tPQm2iwHV+6tZ7Wxl XE7qEQKuG/0JQ== Received: from localhost (localhost [127.0.0.1]) by gentwo.de (Postfix) with ESMTP id C5DACB0005A; Wed, 8 Jun 2022 14:23:45 +0200 (CEST) Date: Wed, 8 Jun 2022 14:23:45 +0200 (CEST) From: Christoph Lameter To: Rongwei Wang cc: David Rientjes , songmuchun@bytedance.com, Hyeonggon Yoo <42.hyeyoo@gmail.com>, akpm@linux-foundation.org, vbabka@suse.cz, roman.gushchin@linux.dev, iamjoonsoo.kim@lge.com, penberg@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/3] mm/slub: fix the race between validate_slab and slab_free In-Reply-To: <29723aaa-5e28-51d3-7f87-9edf0f7b9c33@linux.alibaba.com> Message-ID: References: <20220529081535.69275-1-rongwei.wang@linux.alibaba.com> <9794df4f-3ffe-4e99-0810-a1346b139ce8@linux.alibaba.com> <29723aaa-5e28-51d3-7f87-9edf0f7b9c33@linux.alibaba.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 2726040004 X-Stat-Signature: rkru3wu3uknkqntce16yhknanodsi89i X-Rspam-User: Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gentwo.de header.s=default header.b="ujq/NsBN"; spf=pass (imf07.hostedemail.com: domain of cl@gentwo.de designates 161.97.139.209 as permitted sender) smtp.mailfrom=cl@gentwo.de; dmarc=pass (policy=none) header.from=gentwo.de X-HE-Tag: 1654691028-774787 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, 8 Jun 2022, Rongwei Wang wrote: > If available, I think document the issue and warn this incorrect behavior is > OK. But it still prints a large amount of confusing messages, and disturbs us? Correct it would be great if you could fix this in a way that does not impact performance. > > are current operations on the slab being validated. > And I am trying to fix it in following way. In a short, these changes only > works under the slub debug mode, and not affects the normal mode (I'm not > sure). It looks not elegant enough. And if all approve of this way, I can > submit the next version. > > Anyway, thanks for your time:). > -wrw > > @@ -3304,7 +3300,7 @@ static void __slab_free(struct kmem_cache *s, struct > slab *slab, > > { > void *prior; > - int was_frozen; > + int was_frozen, to_take_off = 0; > struct slab new; to_take_off has the role of !n ? Why is that needed? > - do { > - if (unlikely(n)) { > + spin_lock_irqsave(&n->list_lock, flags); > + ret = free_debug_processing(s, slab, head, tail, cnt, addr); Ok so the idea is to take the lock only if kmem_cache_debug. That looks ok. But it still adds a number of new branches etc to the free loop. Some performance tests would be useful.