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 22546C3ABC0 for ; Thu, 8 May 2025 04:47:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E061D6B000A; Thu, 8 May 2025 00:47:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DB4106B0082; Thu, 8 May 2025 00:47:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C7A1E6B0085; Thu, 8 May 2025 00:47:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id AA8046B000A for ; Thu, 8 May 2025 00:47:45 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id CC35ABFE65 for ; Thu, 8 May 2025 04:47:46 +0000 (UTC) X-FDA: 83418507732.01.FD7CCAA Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) by imf22.hostedemail.com (Postfix) with ESMTP id 055A1C0008 for ; Thu, 8 May 2025 04:47:44 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=W2g3GufW; spf=pass (imf22.hostedemail.com: domain of aha310510@gmail.com designates 209.85.216.44 as permitted sender) smtp.mailfrom=aha310510@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746679665; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=X2W4E+E206TPeQz0Gg8peXL5wASK6C7fNQHKs+qGsPs=; b=x8j4vZJjoHwYBl1cjfhStv+PU9wzMInvFnvR7u056baPB/eN4njNbhSccmt7yUA7/EiimU LV8ZE8S/yJhOmen0VnEBSJVFjSbNxgS/ONrcjrNe4f6IimilY1gA9H6bgnuVyq6KC1Vr76 nzB/0Lg+T3hcfhq35Qmzh17DuNvnZV8= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=W2g3GufW; spf=pass (imf22.hostedemail.com: domain of aha310510@gmail.com designates 209.85.216.44 as permitted sender) smtp.mailfrom=aha310510@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746679665; a=rsa-sha256; cv=none; b=YZ2w7eIAb0vRbkhT+HHdO7as7mQUa7RLAjfs6ZODSBmuYRsvzD/ENjAyFsVBiYusieaUVK 22VIhwbkPGZZlmLJt119kLmu4C91xhQ0HIMY85ISMeZFt53CNojNtKv3QMzo1g1IFbyYy7 MuHagC7sKQXzR0klUbCd7m8MhACIqts= Received: by mail-pj1-f44.google.com with SMTP id 98e67ed59e1d1-30a93d80a80so510982a91.3 for ; Wed, 07 May 2025 21:47:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746679664; x=1747284464; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=X2W4E+E206TPeQz0Gg8peXL5wASK6C7fNQHKs+qGsPs=; b=W2g3GufWKz9JI5vdGDeYoGnvozTSumlnAc6Lz4UQXsPCQvVTR9+l86Gi3FbfSNA5Ze f+72OnLBTU0t0OI17tQd+QgV2Ljat0wIRQl1E6X0rvq8Q1qAMkoibXPH4GKt0P0TRfbU 326GTbRzu19je1BQQ0l8CuMZwPBnA0UopkAeYFJwWmv4nTtA3H5Q13NsOFRzGS+tdc8G pSuuS73+fhkQVth84PYxewVwN+K5d6/YUWryZ4qrdspyd+dnBVa3u1htTydpPBDKFfwO M6v/xL2mF+BE7mSkCqBQFpazETQE6h3HrUbEdH+GgFCEZ6paEUZGctH7exdKfX7H09H9 tcTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746679664; x=1747284464; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=X2W4E+E206TPeQz0Gg8peXL5wASK6C7fNQHKs+qGsPs=; b=dciFHhfHL9e42YkVCA+kS0EzB850j4YV6sNAWJpqzeB+glwxg+IPJODSSBnC86UWGj hKts7r78OsQuvSA/FDl0L9vBWFWxx8yE2eEn74tPVXo7uQ0iPTexMy7+gZVA2bPPoHip 213fqe8jzpR2OJPkLM2O4W+GOrf5LvxWXRQveiaSqpsrQhGo4WdszAC01fnFhaZS4yUS qQqI4EKnznAFyJSVszOuBs3uaa8GqtCJdZ7g4/oknu0+UtNbT7aHPBMIXpciMi2NYzni XEehCm/TU64Zi1qlEGynboclDUi9BjmY1jcrHKooemjlPR62zK7rYEn/0xN9PifrAxAZ CPzQ== X-Forwarded-Encrypted: i=1; AJvYcCWmbI/C3/iOkMnxIFZoZyQJTkegxCsAvx3PDUSLOBoTVBxGyIgXlYfWiBu39FC8ux4QjNhzenP8kA==@kvack.org X-Gm-Message-State: AOJu0YxN5caHol1wbGFTuy5PX8QO2kkVN4fyWKsoi4u62zVKCeR6oBUo pnPJK7gFD6g0MTea9/xfEwEsoj+LIYJfgBSuDXOBQJqCb1k7RjC9dNt6fqiwZLINhh8AA9FKZh3 0yOg84Y946OfdZGneUztJA/bQWa8= X-Gm-Gg: ASbGncurz8Isz87PmBXftsR0V8x4wxDSAFOTZZOvKbsK0Z06/iKpkjgCLaO/vMl5a7C f3URkhnHZpabxlSRARLTJmYrD8eZc3tS1bcayS0WGV3TmIN2WXEhF9fSp/lD8omNPgmVll+9noD gQhYxNd11lI6OkWV55VdSKlg== X-Google-Smtp-Source: AGHT+IGn0YxzjRhYInxhZtobUnfu8EVoeL6K/f/7FuGYolQyFAj4Iiby+/yTGlujnYXAXZcIIwoaq4a+SCIludNnFSM= X-Received: by 2002:a17:90b:164e:b0:2ff:6bd0:ff26 with SMTP id 98e67ed59e1d1-30aac25c713mr7278789a91.34.1746679663794; Wed, 07 May 2025 21:47:43 -0700 (PDT) MIME-Version: 1.0 References: <20250507142552.9446-1-aha310510@gmail.com> <20250507153325.48726051dbbff4f3936a83ff@linux-foundation.org> In-Reply-To: <20250507153325.48726051dbbff4f3936a83ff@linux-foundation.org> From: Jeongjun Park Date: Thu, 8 May 2025 13:47:32 +0900 X-Gm-Features: ATxdqUFEsSOnWPsEnSbopEwhDYTZiEYfrxLptEw3ochwi3pXNJrneqnI3VfNaFQ Message-ID: Subject: Re: [PATCH v3] mm/vmalloc: fix data race in show_numa_info() To: Andrew Morton Cc: urezki@gmail.com, edumazet@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 055A1C0008 X-Stat-Signature: dzkboeh3app5b3aiio9h4aubasex1db5 X-HE-Tag: 1746679664-169471 X-HE-Meta: U2FsdGVkX18f2vYYBWDAb/ZvsRpSJHIvXqru4Ck+FRFMlvq7miW1XaVCgziZXAxm4mstQku+KrZ6IsG2H1+XAK7YLeLT8KhQAJo4Y4CkJmj1UP4Kb8467Tl383uhse3Qx4o0IUxxqJHBgqzf21bvcHMJ1bd9lYe8xXkb6I5N+kzt5Dl1iTFUj1STZTe4pQjTHQMaM+FbSdZ/7A5pce3UWoxTDPBhn3KFwO3DDxhTlVQOLHuTo0+u8+guAdsClWXr2RYiSUi17qJSIvL318K7Xlijsqx1arnscBrqgQq0eQD+sdEVWU80uytxgvexA/oLJq/bJjCLfM41rHRkxiBIxwquAFAVXjRkbTvFkaiwCK7y5vVre/vzgnXmuPVLeeyiCSW8EZ+LOIED31HcScmaG+zd7f9JlGJMZY0OXBkKAMJ8zejFv624MlQ69n+88pwNx8Sl8aKnGrGMVjc6P+RTQtLZAPHBsjYhnGlHQBTH9gYSaUYmGCL2YUELKU6K7RdTT2N6Yi4nwri9glaBiBMDu6o8LyYeNvDZjOPQIc2JTjs4JO7lB8ZXX+wo+iUOCJ1Chod3CAk5aDTUOGzRfFBsPklUo4Jl3+TS/4XmDdGhwnUCx51SBWDP7nPHHpvGUJ77EKKptvm/V/J7vHcIq3BMQo6ej+GPC/EKE3cOXIBFY3+4oUhtRWHbxupLeFQgJRSOlap3nrFxrCmPFZNgCzSNY4dCzqsIbsir7t4inP29OPmEA+XeWQjbffvKMbJPECNf71ir8dW+8wZEm+oLxs5UvauAnqqQtjzg5wavhfgHTDe/cOWKkc0h0kTkWM0cGMisrRZTWeHsTXGtlkxs55mfDvAY2efRTybmIXbifHk7C9kRY7W+bOPZFS2hdA9KmWnlwnmCCOUkHB/TtU+i0IvXI62cXmhcEovT+lRClojt2zvzNJgWf7SUe/bSiJzbduSY0XjI9yYGW+bxAs6z3ML 4L+aHxpz cN0DAN0/YcMfLWQI+wypBOXFSEkJribDQSxYfeWfSy6LSnXkule+/iBlbnqDxn2VvfPNGGbZa63nf2WYPfxXLXxt6f4zuijZ/R6Fo31xhCg/GkTwZa/atrL0P9O/Czx/GdsB/4bMEBn7ICSx+cFIw8D2UMdPpf9oaIPxWIxzvA8eT9CwMNxqPtWqIZlA6FzJh5rtgadsl3AbVDS2d5g5OCBfGuvOamuXo8BcLryBA5qWKVIghlHLymuHMLHOjWoFGB0+SKUnMVtMRVnQwdA4YWM/myhAHotGzHJzg8yA597/HETH6Ko+vM0m662mz5RWQ38kNkexR0opYISJQ43nsNWjwGEIqm4ASpodKXXFREnmJ3dWoKhx2vGKO7NXLLcgg8GIo/+w7d9AQn6wvMjVQVPamUwBzJO5jWicn1h8fPgkPQxDHP3NLQCwR0+TwIhVQPFZl 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: List-Subscribe: List-Unsubscribe: Andrew Morton wrote: > > On Wed, 7 May 2025 23:25:52 +0900 Jeongjun Park wrote: > > > The following data-race was found in show_numa_info(): > > > > ... > > > > > > According to this report, there is a read/write data-race because m->private > > is accessible to multiple CPUs. To fix this, instead of allocating the heap > > in proc_vmalloc_init() and passing the heap address to m->private, > > show_numa_info() should allocate the heap. > > > > One thing to note is that show_numa_info() is called in a critical section > > of a spinlock, so it must be allocated on the heap with GFP_ATOMIC flag. > > GFP_ATOMIC is unfortunate. Can vmalloc_info_show() allocate the > storage outside the lock and pass that pointer into show_numa_info()? > That way will be more efficient also, less allocating and freeing. > > That's good idea! Definitely, if you modify vmalloc_info_show() to allocate the heap before taking the spinlock and initialize the heap to 0 at the beginning of the loop, we don't need to use GFP_ATOMIC, and we only need to allocate the heap once, which is much more efficient. I'll send you v4 patch that reflects this right away. Regards, Jeongjun Park