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 46C42C4706C for ; Sat, 13 Jan 2024 09:13:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B26D16B008C; Sat, 13 Jan 2024 04:13:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AD79E6B0092; Sat, 13 Jan 2024 04:13:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 99EE26B0093; Sat, 13 Jan 2024 04:13:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 8AB336B008C for ; Sat, 13 Jan 2024 04:13:00 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 51C1E401A9 for ; Sat, 13 Jan 2024 09:13:00 +0000 (UTC) X-FDA: 81673723320.08.0F83290 Received: from mail-ua1-f49.google.com (mail-ua1-f49.google.com [209.85.222.49]) by imf25.hostedemail.com (Postfix) with ESMTP id A5492A0014 for ; Sat, 13 Jan 2024 09:12:58 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="b9HE/t8I"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of elver@google.com designates 209.85.222.49 as permitted sender) smtp.mailfrom=elver@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705137178; 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=Yo3t4e6P0WumxGPjlAvUPSxdP7muYs1O7d3R9moE3Qk=; b=VC4OkWos0EmXKYFLlYZ/qlzyHc6C+jULWEJ8QDleyoyTj/DHaqT+qmao80n8V9jCB9zVVe hHb7sc3BhJvoMlvuhLVZsgXA/StFO9jKdFuEpoBNoqsAnac1C3Nq7ofDrf5X1zxSimKcG3 CJ9/NkztPXQ0e9gXRYzExAA9gfjeOOE= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="b9HE/t8I"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of elver@google.com designates 209.85.222.49 as permitted sender) smtp.mailfrom=elver@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705137178; a=rsa-sha256; cv=none; b=a2NAydEjAZ9Nh+m/WKF3Tvj4Ef6vJW8PSJFjmXbLHd8ntoxiixJo4wFhqiRIF1Eqp6ziaB QtFopAs5Xb9GaIPm0wUAV7pdyEXqY3F0fWBPN82TccjMcii3sZBjmzTgfsoUnH9zMcw4e0 9GynzZwIJjEk6vhgZJsKDPcqbxzrqjg= Received: by mail-ua1-f49.google.com with SMTP id a1e0cc1a2514c-7cedcea89a0so71366241.1 for ; Sat, 13 Jan 2024 01:12:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1705137177; x=1705741977; 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=Yo3t4e6P0WumxGPjlAvUPSxdP7muYs1O7d3R9moE3Qk=; b=b9HE/t8I3uhGZqIN0Xc6QJAJuLcOWgzkaxxKrNyTXsXeMnZ1eumy7B+VBdjFgtIeD7 5wPBI+f6zvh81Ruqem1gLB7sJCdnzyAcyZnTlu2TJzTRORoF/XHBMe+E9XsOY0fxYTiD hHNi0ETzAObMLkWe3NLf3D7RvSAtii7euQOEU9XqrjEOaw5R1aAIcyDjkXMSnZiXMN2r JTZPbBipe9LthxxsM1QXdGOXcUjGugKI5/uhk1yM09ZgvvXLFH57k5CU709RFoyHfZZ6 V/zQgKyNdmzJ6DNi7Z/qDye2UbwCYGGczZs8sWOAwYzG5TnqV4O1dsLdzNC7uLbc22qL PLfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705137177; x=1705741977; 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=Yo3t4e6P0WumxGPjlAvUPSxdP7muYs1O7d3R9moE3Qk=; b=Ce8PiEZNbPWR/7Eo/Q6VK06EU/76JoN4Xg3hHJfQWTDCa/WtKUiky4xismtgFotVtX O96djn8HuYUJA3yUy22PkIQ2g8VfUkeL0n5Ei1NuwB8WAnLyC3+idmqQCekpTBMqrrrV Tpu+2GpDz/l3O/bGPVHDSw3FWLWORXoqCANniNQQuJuhAQAVKp+iu7UPLQyZSYrKyqJP KpFQ1DWkKcgz1UTN32JOlqqTcmzsVtJn6aM62ZFmcG/IJNJAo/C5Bya1hbKJuLB/IX+I aK3GLbB2uVTHLGycg70T9H6rZ8AlCS71j/OPh5wLRJYLRgjvPU2GDDujbY7n0+JjWPHh dGXA== X-Gm-Message-State: AOJu0Yx780TrxuUVHYoLTdHoz5PjHOWfcs5sakZIGFR1nSI1fSbibGJL wJFmumEgMHQAuxXoqq4o7DUfmxAV/2X/RH7pGIrQ98XPaiQv X-Google-Smtp-Source: AGHT+IHSgAFEp2sE1hMPV6V+JEol7zUdOE9aW8AkTxTmDJqxn4ST6KW1lHetqmPDJVflJV3u79WMJPFmz/9Is98I7t0= X-Received: by 2002:a67:ea53:0:b0:468:e16:1cf9 with SMTP id r19-20020a67ea53000000b004680e161cf9mr1822608vso.60.1705137177555; Sat, 13 Jan 2024 01:12:57 -0800 (PST) MIME-Version: 1.0 References: <9f81ffcc4bb422ebb6326a65a770bf1918634cbb.1700502145.git.andreyknvl@google.com> <87sf34lrn3.fsf@linux.intel.com> In-Reply-To: From: Marco Elver Date: Sat, 13 Jan 2024 10:12:21 +0100 Message-ID: Subject: Re: [PATCH v4 12/22] lib/stackdepot: use read/write lock To: Andi Kleen Cc: Andrey Konovalov , Oscar Salvador , andrey.konovalov@linux.dev, Andrew Morton , Alexander Potapenko , Dmitry Vyukov , Vlastimil Babka , kasan-dev@googlegroups.com, Evgenii Stepanov , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrey Konovalov Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: A5492A0014 X-Stat-Signature: d6r1bjhx3jyyhsgxce7eh7hnkajoiswg X-HE-Tag: 1705137178-171925 X-HE-Meta: U2FsdGVkX18jhUBledqZismoOT5MvRX1pHCNkzL/57fNc3a7hVThs1ZAUw24qdb4cdKq1HAEjkH+WZEawc35YOaQMAMv9AxhHJyOWoyrCjXCVGYu5WtUBqNV7ZQ89ocgqjbVYBXiNVU+DAaue/MPS6AaCbnROGh1YMbUAIt1gPv8ZRDnqZDLgAkycrHrcSYHd8oeKLE4axQ3P1PU9B1q/37pzxP4MFHYQ8EjYCvsdtLW0iJLxLDyXmPG8wJFQ8mDwtD6EMImZ5wLwT1zEUZw2uoJ5vJHk9vcDhB4ZCMP/04bNbemOnLjkWoa7DcG0NxOLBkAuYLm3BHYooCjIi+u7yeBOaU2ajKE65qftFuzu9fqyqzL/gvtaUdNNvxkGV/zaMNLCgCucxR6QQe/1LevqWH9FgeCF6TOj5jQzF8S33bTZIzVJKhOTb8fa7d8txM6HEwuQ1sWkMMAQDZd6iee/XP6+U/73B3ltISguN1gJKnRERPxhAexFnGwyOq+oeUDEyEw5gE94U8dGJDXKaxkvXPM1xRR+8/6zphPQXAvGErI7r+LEwLDpiSkPMDto1kY3Zs75VqvA1ONITifKNdQS+OogvXhuhUrPe+bpeRxXWYGXiJ8fq8L/d+NS/CeStPE5KSaDi30qH2vJiqpyjSqyEfYMBx+qjzgxMXd5YCyFkAaktk8HTKtAnScibC2ajN5wIcwnfNvfo+0R6KRJ68jOlG+tPozIv+ciseepYTZWAm516G6MLAf1Pwy3ZDjcalGJ05PJnmg/31c1Mlb6EGpTr2gojQ4sSH+59VPs1vZ3hIvyLKML2eyqXai7ZPqF5CtzuAveU0Jj1/gWOJu8MYYeh9dywc4h8lR4BpTC182R1feElgbz50oVs8HNdpvYGyVCjoDJxdVUVWYOc06KDa/0MdK5u49/H5TFRWh2L6c/fnBp/QcKplMiBH/jkUkpXGZ1rI2tddomrTlmr449M9 zGhLVBh0 m+g4wVxVoIMKQXGd4wxN7fs6LrOQWa0sMGDRECDlrXmSkrRnciGA7EqzfR9noq5paAhP7SlfkVM3w3egtetU0A3KmU8Q1Y5N8xKJ52YPhlCSV0A+P2q5g0tWBD7JJMYBT+OoCsiaQZWEberKgjv9RELaymPFkUj7yK/jMdJAwJreg5fDYSq/2osBrbe++c663WVMwetrHc6BkP8RIWsobwgismhk1xlLUjLW/zZmqIeD7b/Nl9vw9P/YGwg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000074, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Sat, 13 Jan 2024 at 02:24, Andi Kleen wrote: > > On Fri, Jan 12, 2024 at 11:15:05PM +0100, Marco Elver wrote: > > + /* > > + * Stack traces of size 0 are never saved, and we can simply use > > + * the size field as an indicator if this is a new unused stack > > + * record in the freelist. > > + */ > > + stack->size = 0; > > I would use WRITE_ONCE here too, at least for TSan. This is written with the pool_lock held. > > + return NULL; > > + > > + /* > > + * We maintain the invariant that the elements in front are least > > + * recently used, and are therefore more likely to be associated with an > > + * RCU grace period in the past. Consequently it is sufficient to only > > + * check the first entry. > > + */ > > + stack = list_first_entry(&free_stacks, struct stack_record, free_list); > > + if (stack->size && !poll_state_synchronize_rcu(stack->rcu_state)) > > READ_ONCE (also for TSan, and might be safer long term in case the > compiler considers some fancy code transformation) And this is also only read with the pool_lock held, so it's impossible that there'd be a data race due to size. (And if there is a data race, I'd want KCSAN to tell us because that'd be a bug then.) depot_pop_free() can't be used w/o the lock because it's manipulating the freelist. To be sure, I'm adding a lockdep_assert_held() to depot_pop_free(). > > + return NULL; > > > > + stack = depot_pop_free(); > > + if (WARN_ON(!stack)) > > Won't you get nesting problems here if this triggers due to the print? > I assume the nmi safe printk won't consider it like an NMI. > > > counters[DEPOT_COUNTER_FREELIST_SIZE]++; > > counters[DEPOT_COUNTER_FREES]++; > > counters[DEPOT_COUNTER_INUSE]--; > > + > > + printk_deferred_exit(); > > Ah this handles the WARN_ON? Should be ok then. Yes, the pool_lock critical sections are surrounded by printk_deferred. Thanks, -- Marco