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 278D2C433EF for ; Fri, 3 Jun 2022 03:35:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6E9976B0071; Thu, 2 Jun 2022 23:35:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 698456B0073; Thu, 2 Jun 2022 23:35:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5A8A76B0074; Thu, 2 Jun 2022 23:35:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 4B11B6B0071 for ; Thu, 2 Jun 2022 23:35:43 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 1F5771206B7 for ; Fri, 3 Jun 2022 03:35:43 +0000 (UTC) X-FDA: 79535510166.17.2392030 Received: from out30-131.freemail.mail.aliyun.com (out30-131.freemail.mail.aliyun.com [115.124.30.131]) by imf28.hostedemail.com (Postfix) with ESMTP id 04507C0076 for ; Fri, 3 Jun 2022 03:34:59 +0000 (UTC) X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R111e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04423;MF=rongwei.wang@linux.alibaba.com;NM=1;PH=DS;RN=11;SR=0;TI=SMTPD_---0VFDf1ro_1654227332; Received: from 192.168.31.179(mailfrom:rongwei.wang@linux.alibaba.com fp:SMTPD_---0VFDf1ro_1654227332) by smtp.aliyun-inc.com(127.0.0.1); Fri, 03 Jun 2022 11:35:33 +0800 Message-ID: <9794df4f-3ffe-4e99-0810-a1346b139ce8@linux.alibaba.com> Date: Fri, 3 Jun 2022 11:35:30 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:101.0) Gecko/20100101 Thunderbird/101.0 Subject: Re: [PATCH 1/3] mm/slub: fix the race between validate_slab and slab_free Content-Language: en-US To: Christoph Lameter , David Rientjes , songmuchun@bytedance.com, Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: 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 References: <20220529081535.69275-1-rongwei.wang@linux.alibaba.com> From: Rongwei Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: imf28.hostedemail.com; dkim=none; spf=pass (imf28.hostedemail.com: domain of rongwei.wang@linux.alibaba.com designates 115.124.30.131 as permitted sender) smtp.mailfrom=rongwei.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=alibaba.com X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 04507C0076 X-Rspam-User: X-Stat-Signature: jaifqkh6bjkznb359romrydmeswqbz9c X-HE-Tag: 1654227299-934600 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: Hi, Christoph, David, Muchun and Hyeonggon Thanks for your time. 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! Thanks again for your time:). -wrw On 6/2/22 11:14 PM, Christoph Lameter wrote: > On Mon, 30 May 2022, David Rientjes wrote: > >>> Unconditionally taking n->list_lock will degrade performance. >> >> This is a good point, it would be useful to gather some benchmarks for >> workloads that are known to thrash some caches and would hit this path >> such as netperf TCP_RR. > > Its obvious that adding new spinlocks to some of the hottest functions in > the kernel will degrade performance. This goes against the basic design of > these functions to be as efficient as possible.