From patchwork Mon Nov 20 17:47:05 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: andrey.konovalov@linux.dev X-Patchwork-Id: 13461821 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 AECD2C197A0 for ; Mon, 20 Nov 2023 17:48:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4FE656B034B; Mon, 20 Nov 2023 12:48:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 44D716B0355; Mon, 20 Nov 2023 12:48:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 202DD6B034E; Mon, 20 Nov 2023 12:48:37 -0500 (EST) 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 03CF26B034D for ; Mon, 20 Nov 2023 12:48:37 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id CDADE1CB5ED for ; Mon, 20 Nov 2023 17:48:36 +0000 (UTC) X-FDA: 81479067432.26.467B728 Received: from out-172.mta0.migadu.com (out-172.mta0.migadu.com [91.218.175.172]) by imf02.hostedemail.com (Postfix) with ESMTP id E3ECC80028 for ; Mon, 20 Nov 2023 17:48:34 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=ukcrau9r; spf=pass (imf02.hostedemail.com: domain of andrey.konovalov@linux.dev designates 91.218.175.172 as permitted sender) smtp.mailfrom=andrey.konovalov@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700502515; 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=ul/nKw7kj0oOeSlF9NlnEwH7YAqJQYzQqOqaJ7LWVgY=; b=hrDYqnSRPMjvCEjSP+ddBm+tMFBU0YF297xfmsshzOoUueORi5mW9Mi4phGSIFljxVMO+8 i7jreWpq5qRIsbSb4sdbAvCw802nHU1Q8evoKZVXpVFRPNqbjMwgQPFRg8ysY1piX0yqIP JJPwcCGqfbGd9Io0SPYaL59Y5AtBbhU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700502515; a=rsa-sha256; cv=none; b=eMkJcCBI0ONozLtizbNdfdxVHXu7Oxvm93l+gDkZNQgqyIlRWR0k7GguJVW7Obg9JJ2rtU V3Lg0zYEZyLZSEeEeHKzIbdWxHt//1yvu6OtUmcQwuDwsSRaJDP6aPl2AhsCeLEvj8w3wV 62oY+41CkQKNNU87KMK2P7NiTSMW6Js= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=ukcrau9r; spf=pass (imf02.hostedemail.com: domain of andrey.konovalov@linux.dev designates 91.218.175.172 as permitted sender) smtp.mailfrom=andrey.konovalov@linux.dev; dmarc=pass (policy=none) header.from=linux.dev X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1700502513; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ul/nKw7kj0oOeSlF9NlnEwH7YAqJQYzQqOqaJ7LWVgY=; b=ukcrau9rBSSL43tgTPUpFjw/XmDDuuV7b5Rf6ugJdDIx3eaVAx8V/9PFiPuIgxA8HOVqDI FOv6Ks7qLmHGEak24eJMUo0HQta3weJK4BNrKPY6LbsCGCWMiUh2CgVaukTzBdLG8nj0JF 0fqdYiwEAxqEdM4YGbvK075MNLH3F5M= From: andrey.konovalov@linux.dev To: Andrew Morton Cc: Andrey Konovalov , Marco Elver , Alexander Potapenko , Dmitry Vyukov , Vlastimil Babka , kasan-dev@googlegroups.com, Evgenii Stepanov , Oscar Salvador , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrey Konovalov Subject: [PATCH v4 07/22] lib/stackdepot: fix and clean-up atomic annotations Date: Mon, 20 Nov 2023 18:47:05 +0100 Message-Id: In-Reply-To: References: MIME-Version: 1.0 X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: E3ECC80028 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: zuop9r4ahk6mjjybrka546a7zgayk7a6 X-HE-Tag: 1700502514-52927 X-HE-Meta: U2FsdGVkX1+20BBYnqw3mtoFN8iU3mDRqv1xyMbyQmEnWcOdeoFPgSbvdcexP/RbAmYiXelN7gTzq7v2jz48OtNX2SuFDJD6qX/s3J2WIrPHIMggbBXHHKkHQgv6+/JnjoYu0epD/qjL3OAYtPg3WPQLtyDfLoqIXV5NmXexfnd/LKzdxTFKqn1zgy3D31+21hMTinErHdbTgPQfyGwdajAmlQt0Jujq+Cb1UwGFId0Xh9ik0prVmIDXvurvqnTAHMvzreIS+O9jJJX8e3pfsusDm96hrv2T24XDKdNdidRZefNUoBBC6dL9JkjqlUjUbFsf+2OLVFzVj88ZS4kwQ+b6DyONQ9l13NFbbqRe2stBEHjIpi18HVQORlz/wKZRRRM2yN37NlzYetTqsUJPxgkh0+X9sFPLJ/hp557y4UQU34qvmD8u4BxhRvNI5FjTTZCPgcaqg3vF1eVIHLcMJxy8vP0i9jyQvE3lj65GyQGjpBONs4QVTesDKcGxzvlK2jQwMT/hNGWGl+VzyAbcpVdwFFZpE7xdoJH30Pc9bidizS+Ump5NhPOHG+dv0wF1q7VknA42NR/ekzgaPXbXL4rCyEKlOCUnv41g09xVRc1P85YWmNBjwDD6sZVguS+wLMT3toMAcjARdmzVUoSXRS/d+ZpzawayL5P1aekpjt5r//aIEUv8kQx3dWXkpqAslXfR9WAQSRxGwBKdZlQ4Z6v0UW93oAL4AQyQGghhoVrFSKj/Dy23g+BzfW8+CyIaLb+1tUXG50YyLIjvUTgtirEjqsCqSiWniPIYJC/zMYK4j+G5ine+ZqOdMlPkcAQjWrKvI9Y7pkNAtDIZmnFHIufYQ4HtNZc284IMwVDZpKKzwqyOLK8q1xqUdTst/IjF5/HE0P3XtYrNXEWTL8yrTficPmC2TwqPknvQv2xgcz04WajkTYZyj2MFc0zAcq5IMshPz2pV31x3MO15TPn rDuEDO8m w8lyvwbyXAeL2Ss/u3UY6CgcSPHUXauPNVUBBRZvm66tbEOwYu2QH+c5uRnrjgQ58jGOv 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: Andrey Konovalov Drop smp_load_acquire from next_pool_required in depot_init_pool, as both depot_init_pool and the all smp_store_release's to this variable are executed under the stack depot lock. Also simplify and clean up comments accompanying the use of atomic accesses in the stack depot code. Reviewed-by: Alexander Potapenko Signed-off-by: Andrey Konovalov --- This patch is not strictly required, as the atomic accesses are fully removed in one of the latter patches. However, I decided to keep the patch just in case we end up needing these atomics in the following iterations of this series. Changes v2->v3: - Keep parentheses when referring to functions in comments. - Add comment that explains why depot_init_pool reads next_pool_required non-atomically. Changes v1->v2: - Minor comment fix as suggested by Marco. - Drop READ_ONCE marking for next_pool_required. --- lib/stackdepot.c | 29 ++++++++++++++--------------- 1 file changed, 14 insertions(+), 15 deletions(-) diff --git a/lib/stackdepot.c b/lib/stackdepot.c index 682497dbe081..cfa3c6c7cc2e 100644 --- a/lib/stackdepot.c +++ b/lib/stackdepot.c @@ -231,10 +231,10 @@ static void depot_init_pool(void **prealloc) /* * If the next pool is already initialized or the maximum number of * pools is reached, do not use the preallocated memory. - * smp_load_acquire() here pairs with smp_store_release() below and - * in depot_alloc_stack(). + * Access next_pool_required non-atomically, as there are no concurrent + * write accesses to this variable. */ - if (!smp_load_acquire(&next_pool_required)) + if (!next_pool_required) return; /* Check if the current pool is not yet allocated. */ @@ -255,8 +255,8 @@ static void depot_init_pool(void **prealloc) * At this point, either the next pool is initialized or the * maximum number of pools is reached. In either case, take * note that initializing another pool is not required. - * This smp_store_release pairs with smp_load_acquire() above - * and in stack_depot_save(). + * smp_store_release() pairs with smp_load_acquire() in + * stack_depot_save(). */ smp_store_release(&next_pool_required, 0); } @@ -279,7 +279,7 @@ depot_alloc_stack(unsigned long *entries, int size, u32 hash, void **prealloc) /* * Move on to the next pool. - * WRITE_ONCE pairs with potential concurrent read in + * WRITE_ONCE() pairs with potential concurrent read in * stack_depot_fetch(). */ WRITE_ONCE(pool_index, pool_index + 1); @@ -287,8 +287,8 @@ depot_alloc_stack(unsigned long *entries, int size, u32 hash, void **prealloc) /* * If the maximum number of pools is not reached, take note * that the next pool needs to initialized. - * smp_store_release() here pairs with smp_load_acquire() in - * stack_depot_save() and depot_init_pool(). + * smp_store_release() pairs with smp_load_acquire() in + * stack_depot_save(). */ if (pool_index + 1 < DEPOT_MAX_POOLS) smp_store_release(&next_pool_required, 1); @@ -329,7 +329,7 @@ static struct stack_record *depot_fetch_stack(depot_stack_handle_t handle) { union handle_parts parts = { .handle = handle }; /* - * READ_ONCE pairs with potential concurrent write in + * READ_ONCE() pairs with potential concurrent write in * depot_alloc_stack(). */ int pool_index_cached = READ_ONCE(pool_index); @@ -419,8 +419,7 @@ depot_stack_handle_t __stack_depot_save(unsigned long *entries, /* * Fast path: look the stack trace up without locking. - * The smp_load_acquire() here pairs with smp_store_release() to - * |bucket| below. + * smp_load_acquire() pairs with smp_store_release() to |bucket| below. */ found = find_stack(smp_load_acquire(bucket), entries, nr_entries, hash); if (found) @@ -430,8 +429,8 @@ depot_stack_handle_t __stack_depot_save(unsigned long *entries, * Check if another stack pool needs to be initialized. If so, allocate * the memory now - we won't be able to do that under the lock. * - * The smp_load_acquire() here pairs with smp_store_release() to - * |next_pool_inited| in depot_alloc_stack() and depot_init_pool(). + * smp_load_acquire() pairs with smp_store_release() in + * depot_alloc_stack() and depot_init_pool(). */ if (unlikely(can_alloc && smp_load_acquire(&next_pool_required))) { /* @@ -457,8 +456,8 @@ depot_stack_handle_t __stack_depot_save(unsigned long *entries, if (new) { new->next = *bucket; /* - * This smp_store_release() pairs with - * smp_load_acquire() from |bucket| above. + * smp_store_release() pairs with smp_load_acquire() + * from |bucket| above. */ smp_store_release(bucket, new); found = new;