Received: by 2002:a05:7412:e794:b0:fa:551:50a7 with SMTP id o20csp651436rdd; Tue, 9 Jan 2024 15:53:21 -0800 (PST) X-Google-Smtp-Source: AGHT+IETYrHJnsPKgMxuKjT60HvfYc4dhJQPc9Bk1jsPEYiDfuHgk/2mk4eCnKW8QgjGpangpd2I X-Received: by 2002:a17:902:f684:b0:1d5:693a:88fc with SMTP id l4-20020a170902f68400b001d5693a88fcmr1333834plg.44.1704844401570; Tue, 09 Jan 2024 15:53:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704844401; cv=none; d=google.com; s=arc-20160816; b=Decxs3AsM28SvtQKVth5yD1vKVEScS3F7lHEE2GpjdfNaBKycF6lMVYEq1I+KQegxJ YExMpLS9Q3mrUTkCEP9CUW16XX9m2S3qHt6ERGLvo6GAdlbSi4xzeHmMf56kyeV19f+3 lMtWfBmGm5Xa7gx34c5jPNG9yxLoBpTbROM1vRH/1yL4sh9Gg/1+HX/ZAIQAer2bcjxx Zlj7KLO4iM7GqCvwNkVO9d3riWij0lGpg0+LeaAEd3W1Y4hD+A3HxFElKMEjjTUbBIo9 6CAJKtmgtoIDuy3KEhtkDw9QaMtZH0MXB2hijhERjV7++fVoP7hLO6VzdR20UvUPqP17 8dbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:reply-to:message-id :subject:cc:to:from:date:dkim-signature; bh=b78T4QAaevtfL1Fq+idZdtKe0I+xsPiT4okJQOR0Sog=; fh=Y0u7NZl4rLFZtYz1vkXCzMeBmvneWnUFaXFDJKt/HiY=; b=JA2rJnBdged0jL7aDyXKi/3E8pjDiTzKkKMOHAufscYRcHegO2/hjiJI7G3qNcgUGx EeG4+roZ/OENM1TbpLe3fQ5AbZib2ctTBxCYWQWio3qZPRXVBZEoK1x50naGwQMUf2HV j6zOV+PKSIhejPWLBSWLntujtmV6jo3yy4Kw+i4SOE/UNM7YMVnOZAcqwURWu5xHordM uIdh0hiQwPbyyisq2GnkVviWMCfZG40fw207xwEOVpdK/Xd+Ng7S0teNJgbvVSgsgsDj C7usodN3fozMA+6HYZsK71zkj2NiwxzF5gyZBJIFWvQQcHodltx/daiH9LYxd1WH1Xhj gJGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=GQeKOsM9; spf=pass (google.com: domain of linux-kernel+bounces-21551-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-21551-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id s133-20020a632c8b000000b005ce07907cb2si2253430pgs.422.2024.01.09.15.53.21 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jan 2024 15:53:21 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-21551-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=GQeKOsM9; spf=pass (google.com: domain of linux-kernel+bounces-21551-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-21551-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id CF7ECB23E0B for ; Tue, 9 Jan 2024 23:53:12 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0B4D33E48E; Tue, 9 Jan 2024 23:53:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GQeKOsM9" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 43ACB3E480 for ; Tue, 9 Jan 2024 23:53:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id ADA85C433F1; Tue, 9 Jan 2024 23:53:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1704844384; bh=vwKOfafdCokp96wmQa5YnL/u1Ge2PlNEhiViBts/sFs=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=GQeKOsM9loQGp1zsYZo2Ns4aITy4Bx5NsNZ6NpeGLfODyY2WIFfPB11V+dLP4hQP/ wZw/arEokJSSZIdgE+A5vuuFSBVevUvYvs+uPBjegwHctA3P+MlF/9Cx1b1eEMLC8U x35olFTHZDwmeBdk+F9EbS9pcG2HbFz821JRhGjgNAj1GMO1HYD+TpnjrtVTF8UYcz sjSx8BYq3e1nKhokkvC33C4ejGxWbNBOkUzNtbnW4h3H6iOnSH3m+9/fVxi0K2tKJK wNiKbe0ozv259XI60pWL3eO84tIipxR9aTBLBSHbL0GACiQD71UXRjNphMaSoBUZee DkVecu0kPFhJA== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 485A0CE15CD; Tue, 9 Jan 2024 15:53:04 -0800 (PST) Date: Tue, 9 Jan 2024 15:53:04 -0800 From: "Paul E. McKenney" To: andrey.konovalov@linux.dev Cc: Andrew Morton , Andrey Konovalov , Marco Elver , Alexander Potapenko , Dmitry Vyukov , Andrey Ryabinin , kasan-dev@googlegroups.com, linux-mm@kvack.org, Liam.Howlett@oracle.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH mm] kasan: avoid resetting aux_lock Message-ID: Reply-To: paulmck@kernel.org References: <20240109221234.90929-1-andrey.konovalov@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240109221234.90929-1-andrey.konovalov@linux.dev> On Tue, Jan 09, 2024 at 11:12:34PM +0100, andrey.konovalov@linux.dev wrote: > From: Andrey Konovalov > > With commit 63b85ac56a64 ("kasan: stop leaking stack trace handles"), > KASAN zeroes out alloc meta when an object is freed. The zeroed out data > purposefully includes alloc and auxiliary stack traces but also > accidentally includes aux_lock. > > As aux_lock is only initialized for each object slot during slab > creation, when the freed slot is reallocated, saving auxiliary stack > traces for the new object leads to lockdep reports when taking the > zeroed out aux_lock. > > Arguably, we could reinitialize aux_lock when the object is reallocated, > but a simpler solution is to avoid zeroing out aux_lock when an object > gets freed. > > Reported-by: Paul E. McKenney > Closes: https://lore.kernel.org/linux-next/5cc0f83c-e1d6-45c5-be89-9b86746fe731@paulmck-laptop/ > Fixes: 63b85ac56a64 ("kasan: stop leaking stack trace handles") > Signed-off-by: Andrey Konovalov Very good! Tested-by: Paul E. McKenney > --- > mm/kasan/generic.c | 10 ++++++++-- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c > index 24c13dfb1e94..df6627f62402 100644 > --- a/mm/kasan/generic.c > +++ b/mm/kasan/generic.c > @@ -487,6 +487,7 @@ void kasan_init_object_meta(struct kmem_cache *cache, const void *object) > __memset(alloc_meta, 0, sizeof(*alloc_meta)); > > /* > + * Prepare the lock for saving auxiliary stack traces. > * Temporarily disable KASAN bug reporting to allow instrumented > * raw_spin_lock_init to access aux_lock, which resides inside > * of a redzone. > @@ -510,8 +511,13 @@ static void release_alloc_meta(struct kasan_alloc_meta *meta) > stack_depot_put(meta->aux_stack[0]); > stack_depot_put(meta->aux_stack[1]); > > - /* Zero out alloc meta to mark it as invalid. */ > - __memset(meta, 0, sizeof(*meta)); > + /* > + * Zero out alloc meta to mark it as invalid but keep aux_lock > + * initialized to avoid having to reinitialize it when another object > + * is allocated in the same slot. > + */ > + __memset(&meta->alloc_track, 0, sizeof(meta->alloc_track)); > + __memset(meta->aux_stack, 0, sizeof(meta->aux_stack)); > } > > static void release_free_meta(const void *object, struct kasan_free_meta *meta) > -- > 2.25.1 >