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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E243DC83F15 for ; Wed, 30 Aug 2023 19:23:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242646AbjH3TWw (ORCPT ); Wed, 30 Aug 2023 15:22:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37780 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242788AbjH3JiS (ORCPT ); Wed, 30 Aug 2023 05:38:18 -0400 Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 65D67137 for ; Wed, 30 Aug 2023 02:38:15 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-401d67434daso15764935e9.2 for ; Wed, 30 Aug 2023 02:38:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1693388294; x=1693993094; darn=vger.kernel.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=V7w982v/e1jzg2/UemZ2RnWkspcdmAHHRTHnHv5ffU8=; b=TJnldFgh6WMQBB2ZnNUL+hwygTKI17JjQUw6UdkiOa/2fLxwzaCHvw57ee/r/WM4+F KVfZjvh1OnicJ3NKmk+96jjFhtb8w7JMcXCq1rGW76kpuUORWxz74AncFtzmQh43RSOs N9nL3+Mr2/KVxNJBqoB8AwcqgHguF8ARJdftlTwxYeYF/FbCvCLUO0lItnw1CTd3AVTk vK5QsAev5o8BV/WWB/1dbNMPEbUVZCbmRk3A8gvC9jtYnRTFxOYIaVndsRzITb7tIwhk jelwlOk8NMcorL4T2dmYCPyaUuZTxcRmNBcsDD7/a6M0HOLemd3Yqy/eU6uq9kxkDupg Qsfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693388294; x=1693993094; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=V7w982v/e1jzg2/UemZ2RnWkspcdmAHHRTHnHv5ffU8=; b=fViT2jljFV5OCOzyvxWVP09vl2waeU2CaJ/76XweJJ97L5GaT+CEf3oBZ7CkJCK/4Y bGdoHn3Mf31p++bLNcGRWH+YuuYKrLWi6Evkyi/KEVar0bKWTV6UMEXQthlz6GP4TIS3 hOm5ypv0UTp+NzEGHHbdeeg8QnCZ6XwrcYPEwcLze4TM/0y/HlNEGVn/dbdvArpke+Rz Mw/KcKdTvjmc/ufPx3NJ7PK4A0arWXQNT8FNrPcpQqRVVK7Gv9JBJO7AxB1zNfA0XPCO tGGZ+ZMIfBpTCneyFs5Cf+2iR22npAaUhW+PqQEq7D5JrJcR53n47bQE6OzNh8T83czX WB3g== X-Gm-Message-State: AOJu0YxaDATAqoOuCkudAx6PEy7mxPNZQ+0w78KAGdB2DI7S/+KVI4nH AdNsNfeebcpnfFNmgzxOSaVfxg== X-Google-Smtp-Source: AGHT+IH7T4lA8VKDVfX4ZbWxQucDyzEIV4N2/dAMItsXboYSXdL36/SsL46Qx29abbIde5hUVuPovg== X-Received: by 2002:a7b:c8c3:0:b0:3fe:d71a:d84e with SMTP id f3-20020a7bc8c3000000b003fed71ad84emr1520377wml.1.1693388293802; Wed, 30 Aug 2023 02:38:13 -0700 (PDT) Received: from elver.google.com ([2a00:79e0:9c:201:3380:af04:1905:46a]) by smtp.gmail.com with ESMTPSA id g15-20020a5d46cf000000b0031762e89f94sm16003691wrs.117.2023.08.30.02.38.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Aug 2023 02:38:13 -0700 (PDT) Date: Wed, 30 Aug 2023 11:38:08 +0200 From: Marco Elver To: andrey.konovalov@linux.dev Cc: Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vlastimil Babka , kasan-dev@googlegroups.com, Evgenii Stepanov , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrey Konovalov Subject: Re: [PATCH 15/15] kasan: use stack_depot_evict for tag-based modes Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.2.9 (2022-11-12) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 29, 2023 at 07:11PM +0200, andrey.konovalov@linux.dev wrote: > From: Andrey Konovalov > > Evict stack traces from the stack depot for the tag-based KASAN modes > once they are evicted from the stack ring. > > Signed-off-by: Andrey Konovalov > --- > mm/kasan/tags.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/mm/kasan/tags.c b/mm/kasan/tags.c > index 7dcfe341d48e..fa6b0f77a7dd 100644 > --- a/mm/kasan/tags.c > +++ b/mm/kasan/tags.c > @@ -96,7 +96,7 @@ static void save_stack_info(struct kmem_cache *cache, void *object, > gfp_t gfp_flags, bool is_free) > { > unsigned long flags; > - depot_stack_handle_t stack; > + depot_stack_handle_t stack, old_stack; > u64 pos; > struct kasan_stack_ring_entry *entry; > void *old_ptr; > @@ -120,6 +120,8 @@ static void save_stack_info(struct kmem_cache *cache, void *object, > if (!try_cmpxchg(&entry->ptr, &old_ptr, STACK_RING_BUSY_PTR)) > goto next; /* Busy slot. */ > > + old_stack = READ_ONCE(entry->stack); Why READ_ONCE? Is it possible that there is a concurrent writer once the slot has been "locked" with STACK_RING_BUSY_PTR? If there is no concurrency, it would be clearer to leave it unmarked and add a comment to that effect. (I also think a comment would be good to say what the WRITE_ONCE below pair with, because at this point I've forgotten.) > WRITE_ONCE(entry->size, cache->object_size); > WRITE_ONCE(entry->pid, current->pid); > WRITE_ONCE(entry->stack, stack); > @@ -131,6 +133,9 @@ static void save_stack_info(struct kmem_cache *cache, void *object, > smp_store_release(&entry->ptr, (s64)object); > > read_unlock_irqrestore(&stack_ring.lock, flags); > + > + if (old_stack) > + stack_depot_evict(old_stack); > } > > void kasan_save_alloc_info(struct kmem_cache *cache, void *object, gfp_t flags) > -- > 2.25.1 >