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 712DFC48297 for ; Fri, 9 Feb 2024 07:46:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F1A536B0078; Fri, 9 Feb 2024 02:46:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EAA5C6B007E; Fri, 9 Feb 2024 02:46:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D918D6B0080; Fri, 9 Feb 2024 02:46:01 -0500 (EST) 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 C71A36B0078 for ; Fri, 9 Feb 2024 02:46:01 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 27F74140114 for ; Fri, 9 Feb 2024 07:46:01 +0000 (UTC) X-FDA: 81771481722.08.47BF5FF Received: from mail-vk1-f175.google.com (mail-vk1-f175.google.com [209.85.221.175]) by imf25.hostedemail.com (Postfix) with ESMTP id 6FA28A0013 for ; Fri, 9 Feb 2024 07:45:59 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=MFRgBTDn; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of elver@google.com designates 209.85.221.175 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=1707464759; 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=fLYosVJBxJJ3XJbpjWGEbQR6KVWU5Ojl+eaZgpRroOc=; b=m0fH2ZMy/n7v/UZTmSmjplyew+D6wgtX2mvjHTK9uwM9iucmj/UzZakFX+n2nQzLfpzDpg OwHh/VInJPDoznjRpSMLDYYCGVqZv8gRGSrFsnrhG19gjbDHP9kBT3QGpup84Alw2mZFWt IhMS1l+qa3RqpZPaKuZM53TzZ9BxE98= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=MFRgBTDn; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of elver@google.com designates 209.85.221.175 as permitted sender) smtp.mailfrom=elver@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707464759; a=rsa-sha256; cv=none; b=d63fMXMXcnmEzdonl2w/6V7VJaQX4b+BqAhnS3O61EZGrpIDOmPLVjIzvmYaR2juCuP2rr ZoT1lO/SOOCJv6NOMh9cEO5iwQRT2DUXm59XuVt5rgGZ1X8WzemA9kLr9A8t9FIMprM3Bl B0rZ7HValVg7pE2OeDHdJ/Hr7Bg0tAs= Received: by mail-vk1-f175.google.com with SMTP id 71dfb90a1353d-4c02a647ed9so203059e0c.1 for ; Thu, 08 Feb 2024 23:45:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1707464758; x=1708069558; 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=fLYosVJBxJJ3XJbpjWGEbQR6KVWU5Ojl+eaZgpRroOc=; b=MFRgBTDnOgg1P6WmwpVPcpsUnz46cDI4Tv+rMNR3Fw8osim7qj2/i0wnpE6CWJU/hn iCjWnNqwDQZOfGtGEWeBGgSfeGHnMX201/dSq5hr7F5WyzXToUD8SQNJc2/fx+zF+pj2 C6RknTopYl0PhWSQrdsOiie4YKWx3UWYJWJWqv371rqQoDh9HdGN3w4ZYew5NJCDvZul pXhs7S+nZqZmwL6lUIUuB1TAMzacs9uP6+WD+Nh5R6RvHiJVHk6332eHsADvA0vxMLOX AhXLv+nuQwi4kf9QKu7UDyyKhLPoWppTwl3WJqIk7zfwboTL4TXWOhcVqq/Br3LetHH0 oHHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707464758; x=1708069558; 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=fLYosVJBxJJ3XJbpjWGEbQR6KVWU5Ojl+eaZgpRroOc=; b=cCwxZFSxc+wXLpGqp/K5AwcJLwkosum8NdsVE3WQtrY1galzw8/cQKYzQIeQte9Vzq okIDEoDyS6o2y8hv5t5eGggxXEAsXY2FIb6NjmLsDxWL6Xu7rrlZwbfsB70yKYdI4nd9 02xlPgSfFRErTVYoyy1rZrnrzF6DW/j9IcY6WDaxPcrfJ1/kDKefL8RhuqrCwCwb2ZGa od9I9R9DyKO3GW3B3XcaGLskCwYAMVLscmmopaq9kURJgPfjlFuF58G+jNJ7hUrKmKCH srpmQ7OK7823HpCJAKAKgYJTS9at8PDX2pXaiQjujB3+lTaZFYM9foxaPeA9X0Ykbgx9 G9XQ== X-Gm-Message-State: AOJu0YzbI2eF1toyLrZphix5xtDp9yVmsPVNE11+1x1gpRtk1Wl4uUPt QVDUMWwfT0Q4cDy2pPHS+x+XtIabZYGkJHi2Xj2mm5dbfnIwIJDStWM4LvW5M2A9BMFfPYX8MXf szm7M9OxDQaGdjbsUxJN8iIdKkFdHijAItmKV X-Google-Smtp-Source: AGHT+IG32FbFwNpAajblBAmyGjcvhmq3HE+1JiSLTIXXgP0Iu40Y7J10uH9X0as64ONMZiafoGptcDTUb2j4d/y1GRE= X-Received: by 2002:a1f:ea01:0:b0:4c0:3c09:6f34 with SMTP id i1-20020a1fea01000000b004c03c096f34mr939892vkh.2.1707464758253; Thu, 08 Feb 2024 23:45:58 -0800 (PST) MIME-Version: 1.0 References: <20240208234539.19113-1-osalvador@suse.de> <20240208234539.19113-2-osalvador@suse.de> In-Reply-To: <20240208234539.19113-2-osalvador@suse.de> From: Marco Elver Date: Fri, 9 Feb 2024 08:45:21 +0100 Message-ID: Subject: Re: [PATCH v7 1/4] lib/stackdepot: Move stack_record struct definition into the header To: Oscar Salvador Cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Michal Hocko , Vlastimil Babka , Andrey Konovalov , Alexander Potapenko Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 6FA28A0013 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: ehpoywtcbe3hgahnztxygdowa1ameuzp X-HE-Tag: 1707464759-437241 X-HE-Meta: U2FsdGVkX1+n8DoE9F8CsNWRs2bEqYL7imjS2F3YmoZPj3YPZLZZJyMhCkvdas0VudqQWiV1T9vpjkb5VbswuH1VtM72h0v2uq6h3OWbPbDTD7ojwUoSkWNmVCCT2NcyzpSePCzMSTkRdjFyZp2Fiz3TJTYiQsTYOX6csJh6gElcOmgMwanN+MNFCYPXTNP3tuKwgzDPKFc+eP+G1RpbJrzflwwrgmsnQ3F5OxPwEU5KfarI5T75Hj1F0MiJ4XYzM5Qwa+gC5RhLN9F3NSWh6xdU6ycZKYwtEDuT/VpFxH++x4h1MV7ZfNkYxmjQZFEE79Qs70fXby+6OyMgoGCSoXx1Ka766vJ/RrwOaIqZkqppm8xUasI6ODOUXxrRNoKhKSl3alLcVxvAfFOCiLr2e9X85OzBeQRoR/hmhdceQHeUd0KPT/Eq5obpVn3AKfxkGM3BCvlsl68wT8ZKuRv7C1xskdH9ufhYmBks2rD6m8tVRetWdbCI0vqX7BHzXuqRN2H6gsDF20ja4BR8QJLPbSDlOAdKPiLiPgdcSvT2E9RX7W+17lYyBr1fby4ykdAzQ8g8zH/pBx95KKw4G0joTRBNzpUXNYIs09KVMajARyVH5qxyuh3tnODQHPOIlUH7VzjtPQ+oKaVaLOk5+4d79gde2usDlgaSRBhPpms4DOEkAMRI7sl19LIWTiYXfANHrKbrOEfXfayc5xljtFpNgjM5uIXQ1JUjnwJv7ZuxBhxmK8wr0I+4phUQ2yz7z74NczvWO1jbEMBwY1BVstTJRsVbex67Win7THpJl4eMk8mkq++Yn7Z5YVL6ut5PcgFGyfnGP7jg4SeqxhhzJCpr9KyLAw+RyFH+W6f2GlN32yQ7NblYDwNZV+bwibX1XejDTlIQyVXvF6GXTV2SyzwUx2MxTxnIkxeytVZRRtrXuphaIv0RVnSv3KKxTF0ovhNPrfuM7ePw6YB69K0r9pJ bldqtqIk UxSJnkkIBVSUTv06ezhSqZnjq5vFncoNFke+/dh32Dg8uLTEqsBVrTW8+3uUhQb+cff80OUPygkjmP7ODxYPlQwGBIRhJURROj131DOdC2bKwtQI179BYthqjIdOLR5QBJfU2nzJR22gEHjrEDrBRArxQKVafUzPDmfaepFi8Twz1oH1hHxDLlBYKbnr2WMfv8KxgpTnmHkA0GFrxPbTeAaLWckfINqSEC9QtjRx0PV/asJMeMvf7qEd2pjCGG++LTWhzpAxDu2H01DZ7D7SXFUjDkQ== 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: On Fri, 9 Feb 2024 at 00:45, Oscar Salvador wrote: > > In order to move the heavy lifting into page_owner code, this one > needs to have access to the stack_record structure, which right now > sits in lib/stackdepot.c. > Move it to the stackdepot.h header so page_owner can access > stack_record's struct fields. > > Signed-off-by: Oscar Salvador > --- > include/linux/stackdepot.h | 44 ++++++++++++++++++++++++++++++++++++++ > lib/stackdepot.c | 43 ------------------------------------- > 2 files changed, 44 insertions(+), 43 deletions(-) > > diff --git a/include/linux/stackdepot.h b/include/linux/stackdepot.h > index adcbb8f23600..d0dcf4aebfb4 100644 > --- a/include/linux/stackdepot.h > +++ b/include/linux/stackdepot.h > @@ -30,6 +30,50 @@ typedef u32 depot_stack_handle_t; > */ > #define STACK_DEPOT_EXTRA_BITS 5 > > +#define DEPOT_HANDLE_BITS (sizeof(depot_stack_handle_t) * 8) > + > +#define DEPOT_POOL_ORDER 2 /* Pool size order, 4 pages */ > +#define DEPOT_POOL_SIZE (1LL << (PAGE_SHIFT + DEPOT_POOL_ORDER)) > +#define DEPOT_STACK_ALIGN 4 > +#define DEPOT_OFFSET_BITS (DEPOT_POOL_ORDER + PAGE_SHIFT - DEPOT_STACK_ALIGN) > +#define DEPOT_POOL_INDEX_BITS (DEPOT_HANDLE_BITS - DEPOT_OFFSET_BITS - \ > + STACK_DEPOT_EXTRA_BITS) > + > +/* Compact structure that stores a reference to a stack. */ > +union handle_parts { > + depot_stack_handle_t handle; > + struct { > + u32 pool_index : DEPOT_POOL_INDEX_BITS; > + u32 offset : DEPOT_OFFSET_BITS; > + u32 extra : STACK_DEPOT_EXTRA_BITS; > + }; > +}; > + > +struct stack_record { > + struct list_head hash_list; /* Links in the hash table */ > + u32 hash; /* Hash in hash table */ > + u32 size; /* Number of stored frames */ > + union handle_parts handle; /* Constant after initialization */ > + refcount_t count; > + union { > + unsigned long entries[CONFIG_STACKDEPOT_MAX_FRAMES]; /* Frames */ > + struct { > + /* > + * An important invariant of the implementation is to > + * only place a stack record onto the freelist iff its > + * refcount is zero. Because stack records with a zero > + * refcount are never considered as valid, it is safe to > + * union @entries and freelist management state below. > + * Conversely, as soon as an entry is off the freelist > + * and its refcount becomes non-zero, the below must not > + * be accessed until being placed back on the freelist. > + */ > + struct list_head free_list; /* Links in the freelist */ > + unsigned long rcu_state; /* RCU cookie */ > + }; > + }; > +}; > + > typedef u32 depot_flags_t; > > /* > diff --git a/lib/stackdepot.c b/lib/stackdepot.c > index 5caa1f566553..16c8a1bf0008 100644 > --- a/lib/stackdepot.c > +++ b/lib/stackdepot.c > @@ -35,14 +35,6 @@ > #include > #include > > -#define DEPOT_HANDLE_BITS (sizeof(depot_stack_handle_t) * 8) > - > -#define DEPOT_POOL_ORDER 2 /* Pool size order, 4 pages */ > -#define DEPOT_POOL_SIZE (1LL << (PAGE_SHIFT + DEPOT_POOL_ORDER)) > -#define DEPOT_STACK_ALIGN 4 > -#define DEPOT_OFFSET_BITS (DEPOT_POOL_ORDER + PAGE_SHIFT - DEPOT_STACK_ALIGN) > -#define DEPOT_POOL_INDEX_BITS (DEPOT_HANDLE_BITS - DEPOT_OFFSET_BITS - \ > - STACK_DEPOT_EXTRA_BITS) > #if IS_ENABLED(CONFIG_KMSAN) && CONFIG_STACKDEPOT_MAX_FRAMES >= 32 > /* > * KMSAN is frequently used in fuzzing scenarios and thus saves a lot of stack ^^ This hunk no longer exists, try to rebase against the version in -next. Other than that, this looks fine.