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 20E33CCA47C for ; Tue, 7 Jun 2022 12:14:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3AE0C6B0074; Tue, 7 Jun 2022 08:14:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 35D5D6B0075; Tue, 7 Jun 2022 08:14:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1FD396B0078; Tue, 7 Jun 2022 08:14:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 0D24D6B0074 for ; Tue, 7 Jun 2022 08:14:49 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id CDF3510C1 for ; Tue, 7 Jun 2022 12:14:48 +0000 (UTC) X-FDA: 79551333456.07.4EC6AD6 Received: from gentwo.de (gentwo.de [161.97.139.209]) by imf08.hostedemail.com (Postfix) with ESMTP id F1AE216001E for ; Tue, 7 Jun 2022 12:14:18 +0000 (UTC) Received: by gentwo.de (Postfix, from userid 1001) id C7CEBB0012F; Tue, 7 Jun 2022 14:14:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gentwo.de; s=default; t=1654604085; bh=/15Jtn/l6rflU2k3fwtc3B718k5z91qYrofnha1OCHI=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=wf63nbTf3C53rPmwuG1tCmvb5P2bJo07dXmf3zRdMrTb7TwuGydkqufLv+tVMcya9 AQkGwZ4TwrUqQYhUJJcjXVlMCTouUt6F3TuytbH68ymm55CCZffOW1PgyD+sl96XPu bAgSXiAGZlxSAoyawlxYpncvWYJyxheu3p5M5DKBwEWYRahYstzXtLgZNXjQ7qonr6 /ty98DDgFbbLPKCpSWCUIkNYP3TmnZf8ESSOkkivXRKR/iR+7nsm3W4PjsNFgoZTfd Dr7q8mVlfhyIehMWZpJ6Ty+AqZT7n90thZbDj50dqmttKFYc0xR8igvE14uzCXxFu0 fRliG+LFUciBg== Received: from localhost (localhost [127.0.0.1]) by gentwo.de (Postfix) with ESMTP id C39A7B00060; Tue, 7 Jun 2022 14:14:45 +0200 (CEST) Date: Tue, 7 Jun 2022 14:14: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: <9794df4f-3ffe-4e99-0810-a1346b139ce8@linux.alibaba.com> Message-ID: References: <20220529081535.69275-1-rongwei.wang@linux.alibaba.com> <9794df4f-3ffe-4e99-0810-a1346b139ce8@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-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: F1AE216001E X-Stat-Signature: hyqk6ou35zoxgho7nz5jj4s8qbdta9xa Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gentwo.de header.s=default header.b=wf63nbTf; dmarc=pass (policy=none) header.from=gentwo.de; spf=pass (imf08.hostedemail.com: domain of cl@gentwo.de designates 161.97.139.209 as permitted sender) smtp.mailfrom=cl@gentwo.de X-HE-Tag: 1654604058-514815 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 Fri, 3 Jun 2022, Rongwei Wang wrote: > Recently, I am also find other ways to solve this. That case was provided by > Muchun is useful (Thanks Muchun!). Indeed, it seems that use n->list_lock here > is unwise. Actually, I'm not sure if you recognize the existence of such race? > If all agrees this race, then the next question may be: do we want to solve > this problem? or as David said, it would be better to deprecate validate > attribute directly. I have no idea about it, hope to rely on your experience. > > In fact, I mainly want to collect your views on whether or how to fix this bug > here. Thanks! Well validate_slab() is rarely used and should not cause the hot paths to incur performance penalties. Fix it in the validation logic somehow? Or document the issue and warn that validation may not be correct if there are current operations on the slab being validated.