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 2B91BC25B79 for ; Tue, 28 May 2024 00:57:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 413B26B0088; Mon, 27 May 2024 20:56:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3C37F6B008A; Mon, 27 May 2024 20:56:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 265386B008C; Mon, 27 May 2024 20:56:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 0A0F96B0088 for ; Mon, 27 May 2024 20:56:58 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 7C99714010A for ; Tue, 28 May 2024 00:56:57 +0000 (UTC) X-FDA: 82165990074.30.ED2428A Received: from mail-yw1-f174.google.com (mail-yw1-f174.google.com [209.85.128.174]) by imf29.hostedemail.com (Postfix) with ESMTP id B02E0120002 for ; Tue, 28 May 2024 00:56:55 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=BHXTEgHg; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf29.hostedemail.com: domain of yury.norov@gmail.com designates 209.85.128.174 as permitted sender) smtp.mailfrom=yury.norov@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1716857815; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=CnYdPTK2hjdSIrEV7sBehdeTDvZ879lf0pp/n//Br14=; b=VfbSv7Ipcx7ZLDFz7iBht4aG24E7R/Dd8pMI8lWcY6hqfaonK2b63X8WOO9d6aYRjiSXvB S7cUiWNqqqGCOF9reYeRFn0KO2e+aBJF7598lDzkw+ums4iMrJnpKzcjUuGH48pXHRETHO 8yOXQ5YhL9nQGegzoT06QdI+row6AyY= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=BHXTEgHg; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf29.hostedemail.com: domain of yury.norov@gmail.com designates 209.85.128.174 as permitted sender) smtp.mailfrom=yury.norov@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716857815; a=rsa-sha256; cv=none; b=Gbcdhn6URP1yfCvC3Cdv3/PI5ZMXLS4UpwRLHGVU1KkkDbjrFeuUqo656mBjZS1u7um3Ie IuuYNupqZQcVWiCkMvXVVlawMtXyqopoK83A/xeaLNqnBwrHhppX6d3spYYAFNxZwkdKmC naML5uvSdTi9jW58rylXlzd5nPvWM0I= Received: by mail-yw1-f174.google.com with SMTP id 00721157ae682-62a052f74c1so2144617b3.1 for ; Mon, 27 May 2024 17:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716857815; x=1717462615; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=CnYdPTK2hjdSIrEV7sBehdeTDvZ879lf0pp/n//Br14=; b=BHXTEgHgKxxpJD2o/F+OS/zdJ5S++MFiRJa2sxrV0sW37VrwMg2XpLVWRt0+wlOJ7g bR4WL50vPV77GKQcq36+e8dR4b9r2DjKBErMPFF9fH3bSR3qFZEjuK6teuHhQ+o2EBQP xrRrqUjPIJmMafvOPH3rFX/PzttudQWevBaqJ0xovtIyeM8VsnA6rK4goTNegk1aYGMD AbpeV42eY6PkhQXiMXKXX4piGdeSq3qs0iKgTUPorGqPslpD4NW0AjzdxSivy278UCj6 2TMAXZhaggHUGQ+7EZG2mJdIxRj+weTNkS01oPIw+CrX3R7wJdU8CIHynhNU8kUX/gH4 /mWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716857815; x=1717462615; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=CnYdPTK2hjdSIrEV7sBehdeTDvZ879lf0pp/n//Br14=; b=cQm1tXPZIPj4SNyVmloN1SzOyJSxgkqrP7xri4MEm369tKbaM+JfQkA8GjZVj2ds92 s/Oyydqu6fOmPde6rQsCYCHdpjN8vSBWP/C6KeAsaVyNs/CRG/lflc7A7Y9JK/IXWJBb mzZcFL3+W9oDlZ2XJcgDFSmsAYUiESRMKEa5Q4cuvly8sFGrb7LEckpY/Wood08cjXr/ GAolaMuZs+etPYpqMXnDECJT1E16V1o+MeMYbiWZeRH+UaVXoxECQzZ3Q5QamL1x/cul A+rcC24RRNR0iQggfifFZIdydINE33YUTINRVMtH3mZ5akP//IUndndXtaSOAZSIXr+x UzCg== X-Forwarded-Encrypted: i=1; AJvYcCWM6FBinvwz+0tbv/wq30oaVEc5kP+tbrEaK8SyiV8uanOQ1vlnmE34CGRYzHcZABWMZ2lvl7pEf12fZSlmhvQDadc= X-Gm-Message-State: AOJu0Yy5SROCXUGEAE5EwHZo2bM46puzLp9U9xnMoedh+0tziMghN151 pQl0icJvD4qu4cujurz4Z0NOdk7qJ/7wza0LkofTycLlKsYP6niW X-Google-Smtp-Source: AGHT+IGFLMTRC6NGdZAsWBDoDAamZt9sH7ju82xLanpo1xta++q9GRm1I/nDECPhqHpvKBSqNyQYiA== X-Received: by 2002:a05:690c:c99:b0:618:88d1:f15f with SMTP id 00721157ae682-627fb1ca4c5mr105218897b3.0.1716857814398; Mon, 27 May 2024 17:56:54 -0700 (PDT) Received: from localhost ([2601:344:8301:57f0:35f3:16c3:302:8fdb]) by smtp.gmail.com with ESMTPSA id 00721157ae682-62a0a52eb60sm18506167b3.112.2024.05.27.17.56.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 May 2024 17:56:54 -0700 (PDT) From: Yury Norov To: linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, rcu@vger.kernel.org, linux-trace-kernel@vger.kernel.org Cc: Yury Norov , "Paul E. McKenney" , "Rafael J. Wysocki" , Amit Daniel Kachhap , Andrew Morton , Anna-Maria Behnsen , Christoph Lameter , Daniel Lezcano , Dennis Zhou , Frederic Weisbecker , Johannes Weiner , Juri Lelli , Kees Cook , Mathieu Desnoyers , Peter Zijlstra , Rasmus Villemoes , Tejun Heo , Thomas Gleixner , Ulf Hansson , Vincent Guittot , Viresh Kumar , Zefan Li , Yury Norov Subject: [PATCH 3/6] cpumask: split out include/linux/cpumask_types.h Date: Mon, 27 May 2024 17:56:45 -0700 Message-Id: <20240528005648.182376-4-yury.norov@gmail.com> X-Mailer: git-send-email 2.40.1 In-Reply-To: <20240528005648.182376-1-yury.norov@gmail.com> References: <20240528005648.182376-1-yury.norov@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: B02E0120002 X-Stat-Signature: d6jt3hc3bdksiifqyztmggujax5yukse X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1716857815-380496 X-HE-Meta: U2FsdGVkX1/GCn9Ily2KQFotTK2mcx4MCaC+hxQ0z0KrFzP3X5Wng3HMxqfiXnBsiayVT5d9USKkOraALN7D7kPnsduz6H3aEoe03Mq+rkdn50/ueysR32jSV+SlTtx4mcSER0J6JSLEQBxzfUH9H5h4meF5EAocoZ6IOFJwx+CEQpMgGD6UIVkJoUvFG86qzcwi5GmONGymQ6xlzq9fQyakNTcee4ZZb9klBvoeaO3AgAIdfdxhVAlkL2E/+R3mLY6esD4vwFbffkHuFVebf4Z9KoMtdnAagwpGOLSu77m4FKV0uD2+xcvSQhNN901jKFGxBbyIkfyrQoiYCfUiVQJVp81KwDbwxlrFqO560OgPGw6ZUBg/xGWhXdi66h3tM4pswcd6RqGPv5tLoxfUsZ+X2YWNfjp0VDhgZy7HTAHg6w+xtzRgD+RiBa4wzaB9jhS/ENoMZxYrJR17FMmJoK/ugT5R3UWhI8LkYdUY7zyxMG6p9HIV7luZe1vaDTB8zQ1KhR94fjxroApgoahKrhxY7wGx9bVvkAgVQbcnE4J7TIS1OXY6xaHD8wveHMwr37ADqPpmy9LqSl5K8oGCDJNN+61IgInbJMzZk+pjXzuvHJWSWehV3SfGfC7+qvXaAeXmnZqdj4EWPAh81ah1OBZgNWeBsEY1UBh47LLKUm6CO4ifV8A221c2HPR7/FSWqy1pIb94huQDGPp7ztWHvX1GBLqcca+H8o7QteSMxu7ul7N6Cjwn0mqGg+gOIEjtwcx6OhzARFwXKMa12Xm9vLW0IO0d3JHMv+oHQUlv1q/vhaHo9Y+R2iuf/E0mzLaKP5opXhwls2GaBsNW41l2fO62/CSWFfsQXu3LQl4T9P6ZbefRruOb6+LVchMjKokmbcmClVnDvD7fxIRjWmXlQwjfPEvuump7EdGFr4FhHy6ruBLj8PLJFiTQrqfTNbCd5HBGJJ1Pb2N5P+aNAn7 VaPUKnhb 7nJ1NlKGxwnofAchPxlIts+0FEn5JD7VlbB8zte2deUBKjtB952wjTulLjrqlJoMZjlDToHuAgCFMIlbuxCtpHBLY4FFlB6Y2HxAFXo0VKKfwngfGJRPMZ24E7yU6sMwOkhru88mh9/1q88xKUkf72ZuSGwu7o44kAab75qYPg438XNuRLxeAHNvz7mSU+crVxj59/emLLs7eR034kUfiMyK5kOmC+T9PTu0BsXmt7cAALPfxk7XNubojPMx+AlYftlMYWOx5mmdoRIEeJcXYyq3crH+LFbq2E4b8YheYYXne211pDkcN2Pqd6rA0oTlBl89iJ4/Mos29Rev0/fYwLawzj6jkwaXLhwyROm9RIC1jpscsvIUOsCbF5BbB3iV4QgtV8pCtUmllofpoRQDmnEW1yiOv9ddrwAk/kQ1PXxv4n1E+//tqTbVCcGDVyT+QTCI/EYhxA3J1LyRejKpUzZJExMJOFI42Ff9LqSqSnfynu8e0Ue0WyWr3YzRGK7fjjRd/0ouDl82BubwW/6OiynHW5OVeKRLGGndGBKacnyUTPxFXNOg/qT0SVvXSNFwzPOWyplAxi/aMKSj3OaLrVnlA6ZHNfBUmEzn4QVvudggQX53HcKULiTD2/A== 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: From: Yury Norov Many core headers, like sched.h, include cpumask.h mostly for struct cpumask and cpumask_var_t. Those are frequently used headers and shouldn't pull more than the bare minimum. Signed-off-by: Yury Norov --- MAINTAINERS | 1 + include/linux/cpumask.h | 56 +---------------------------- include/linux/cpumask_types.h | 66 +++++++++++++++++++++++++++++++++++ 3 files changed, 68 insertions(+), 55 deletions(-) create mode 100644 include/linux/cpumask_types.h diff --git a/MAINTAINERS b/MAINTAINERS index 6ae73aaee305..c4fa8f264156 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3731,6 +3731,7 @@ F: include/linux/bitmap-str.h F: include/linux/bitmap.h F: include/linux/bits.h F: include/linux/cpumask.h +F: include/linux/cpumask_types.h F: include/linux/find.h F: include/linux/nodemask.h F: include/linux/nodemask_types.h diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h index 18410acdbc9e..79262a9ef03b 100644 --- a/include/linux/cpumask.h +++ b/include/linux/cpumask.h @@ -9,25 +9,13 @@ */ #include #include -#include #include +#include #include #include #include #include -/* Don't assign or return these: may not be this big! */ -typedef struct cpumask { DECLARE_BITMAP(bits, NR_CPUS); } cpumask_t; - -/** - * cpumask_bits - get the bits in a cpumask - * @maskp: the struct cpumask * - * - * You should only assume nr_cpu_ids bits of this mask are valid. This is - * a macro so it's const-correct. - */ -#define cpumask_bits(maskp) ((maskp)->bits) - /** * cpumask_pr_args - printf args to output a cpumask * @maskp: cpumask to be printed @@ -922,48 +910,7 @@ static inline unsigned int cpumask_size(void) return bitmap_size(large_cpumask_bits); } -/* - * cpumask_var_t: struct cpumask for stack usage. - * - * Oh, the wicked games we play! In order to make kernel coding a - * little more difficult, we typedef cpumask_var_t to an array or a - * pointer: doing &mask on an array is a noop, so it still works. - * - * i.e. - * cpumask_var_t tmpmask; - * if (!alloc_cpumask_var(&tmpmask, GFP_KERNEL)) - * return -ENOMEM; - * - * ... use 'tmpmask' like a normal struct cpumask * ... - * - * free_cpumask_var(tmpmask); - * - * - * However, one notable exception is there. alloc_cpumask_var() allocates - * only nr_cpumask_bits bits (in the other hand, real cpumask_t always has - * NR_CPUS bits). Therefore you don't have to dereference cpumask_var_t. - * - * cpumask_var_t tmpmask; - * if (!alloc_cpumask_var(&tmpmask, GFP_KERNEL)) - * return -ENOMEM; - * - * var = *tmpmask; - * - * This code makes NR_CPUS length memcopy and brings to a memory corruption. - * cpumask_copy() provide safe copy functionality. - * - * Note that there is another evil here: If you define a cpumask_var_t - * as a percpu variable then the way to obtain the address of the cpumask - * structure differently influences what this_cpu_* operation needs to be - * used. Please use this_cpu_cpumask_var_t in those cases. The direct use - * of this_cpu_ptr() or this_cpu_read() will lead to failures when the - * other type of cpumask_var_t implementation is configured. - * - * Please also note that __cpumask_var_read_mostly can be used to declare - * a cpumask_var_t variable itself (not its content) as read mostly. - */ #ifdef CONFIG_CPUMASK_OFFSTACK -typedef struct cpumask *cpumask_var_t; #define this_cpu_cpumask_var_ptr(x) this_cpu_read(x) #define __cpumask_var_read_mostly __read_mostly @@ -1010,7 +957,6 @@ static inline bool cpumask_available(cpumask_var_t mask) } #else -typedef struct cpumask cpumask_var_t[1]; #define this_cpu_cpumask_var_ptr(x) this_cpu_ptr(x) #define __cpumask_var_read_mostly diff --git a/include/linux/cpumask_types.h b/include/linux/cpumask_types.h new file mode 100644 index 000000000000..461ed1b6bcdb --- /dev/null +++ b/include/linux/cpumask_types.h @@ -0,0 +1,66 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef __LINUX_CPUMASK_TYPES_H +#define __LINUX_CPUMASK_TYPES_H + +#include +#include + +/* Don't assign or return these: may not be this big! */ +typedef struct cpumask { DECLARE_BITMAP(bits, NR_CPUS); } cpumask_t; + +/** + * cpumask_bits - get the bits in a cpumask + * @maskp: the struct cpumask * + * + * You should only assume nr_cpu_ids bits of this mask are valid. This is + * a macro so it's const-correct. + */ +#define cpumask_bits(maskp) ((maskp)->bits) + +/* + * cpumask_var_t: struct cpumask for stack usage. + * + * Oh, the wicked games we play! In order to make kernel coding a + * little more difficult, we typedef cpumask_var_t to an array or a + * pointer: doing &mask on an array is a noop, so it still works. + * + * i.e. + * cpumask_var_t tmpmask; + * if (!alloc_cpumask_var(&tmpmask, GFP_KERNEL)) + * return -ENOMEM; + * + * ... use 'tmpmask' like a normal struct cpumask * ... + * + * free_cpumask_var(tmpmask); + * + * + * However, one notable exception is there. alloc_cpumask_var() allocates + * only nr_cpumask_bits bits (in the other hand, real cpumask_t always has + * NR_CPUS bits). Therefore you don't have to dereference cpumask_var_t. + * + * cpumask_var_t tmpmask; + * if (!alloc_cpumask_var(&tmpmask, GFP_KERNEL)) + * return -ENOMEM; + * + * var = *tmpmask; + * + * This code makes NR_CPUS length memcopy and brings to a memory corruption. + * cpumask_copy() provide safe copy functionality. + * + * Note that there is another evil here: If you define a cpumask_var_t + * as a percpu variable then the way to obtain the address of the cpumask + * structure differently influences what this_cpu_* operation needs to be + * used. Please use this_cpu_cpumask_var_t in those cases. The direct use + * of this_cpu_ptr() or this_cpu_read() will lead to failures when the + * other type of cpumask_var_t implementation is configured. + * + * Please also note that __cpumask_var_read_mostly can be used to declare + * a cpumask_var_t variable itself (not its content) as read mostly. + */ +#ifdef CONFIG_CPUMASK_OFFSTACK +typedef struct cpumask *cpumask_var_t; +#else +typedef struct cpumask cpumask_var_t[1]; +#endif /* CONFIG_CPUMASK_OFFSTACK */ + +#endif /* __LINUX_CPUMASK_TYPES_H */ -- 2.40.1