From patchwork Tue Jan 9 22:12:34 2024 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: 186581 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:2411:b0:101:2151:f287 with SMTP id m17csp438092dyi; Tue, 9 Jan 2024 14:13:02 -0800 (PST) X-Google-Smtp-Source: AGHT+IEsoiN/LJhrmvrs0AfujQRFLcWCW8pM3PnMPXKPmF01Ug6JFtKub7Zwk3AG6/NnqDrFQRDS X-Received: by 2002:ac8:7f44:0:b0:429:b267:fa7a with SMTP id g4-20020ac87f44000000b00429b267fa7amr98621qtk.2.1704838382295; Tue, 09 Jan 2024 14:13:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704838382; cv=none; d=google.com; s=arc-20160816; b=PD+8Wj4pdaaViWg8hrVYP8WF5lXJMCw5SU/9EjCcrusNiZIsC/hFUXbtCKl0QGC4tQ nlG3St+4WDwDxCplv4VCCQX3FbS7FSaTZc4GclPFHY+Uktn86cJW0AaR5ZfsG/YIHadm MIvAfJM8xMNUssPFklmGbITYfjrWFZdgnrASztrWXw3GAsgQQjEXU+cLFGfEziRlH8XS s+/d1pYL+nL3XUL9uYh6fwFTvGUHyVHLjQzWt3VK2336yIc4Mgz41RSvbft6KOsEQra1 FwY0mSwzMkGTtDYwN0uP47dk6yLgkEXVWCfmULUpmbamD1KeS+FY/I/PJvzvmugRMXn7 ow0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=+MEfEwS7YBgABTVs4pBpb90gb7WYrZTDLj1svt0+kOQ=; fh=LR59V+RzXHE2yptcMXdGLPI79V/pXZ7ZmyhyqeIltIM=; b=UezuCqf+yborXajB7vLWLiOG9rkhjEXMrAeUTpwJTZ4US1xrvLzNle8gWzOz6fYEBE Es/jJEjHy0XtbJU2v2818vOFdyPAIISwmH28S5/wt8Gdw7m7iNrO+h5w51olQarKvvOi 4N4liuD2PT+cXCN54fhL0ws7GfYaOyBjMeqVG9bzuMSPIWFD2cdMz2BobJX9FuV5PuuJ Nw/2YA+fEo1nj8utfqXlukJAX8lgDLUA6oIt64hxawU5AGZwNCIuLbN4eJ5YABUaRuuX yd+i51DtCTnDoqU8OzF9tM2icRnjC482rbRFnS7lmzMcXWI/xLOUMGpUcN+yg1b2M1ji L6UQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=FeUfEWH8; spf=pass (google.com: domain of linux-kernel+bounces-21460-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-21460-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id l20-20020a05622a175400b004299641759csi3056502qtk.173.2024.01.09.14.13.02 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jan 2024 14:13:02 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-21460-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=FeUfEWH8; spf=pass (google.com: domain of linux-kernel+bounces-21460-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-21460-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev 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 ny.mirrors.kernel.org (Postfix) with ESMTPS id 1B0611C249BC for ; Tue, 9 Jan 2024 22:13:02 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B85E93DBBB; Tue, 9 Jan 2024 22:12:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="FeUfEWH8" Received: from out-179.mta0.migadu.com (out-179.mta0.migadu.com [91.218.175.179]) (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 C44563C6A4 for ; Tue, 9 Jan 2024 22:12:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=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=1704838361; 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; bh=+MEfEwS7YBgABTVs4pBpb90gb7WYrZTDLj1svt0+kOQ=; b=FeUfEWH8NQXFDwxIrMCopRuDErF2CX8T2lyAKILhtxo9p7YHypWHSErr2cSpZ7NUXuCRj4 T99H0foXMcRpFqGJbZ1VYyl9mF0EBh3+tvcP+Jqmi7D0ItBLHKMSuoNecWKmCENC7avZ/F xwbCI/whlohiv7GmWiheHgh8pnDt628= From: andrey.konovalov@linux.dev To: Andrew Morton Cc: Andrey Konovalov , Marco Elver , Alexander Potapenko , Dmitry Vyukov , Andrey Ryabinin , kasan-dev@googlegroups.com, linux-mm@kvack.org, "Paul E . McKenney" , Liam.Howlett@oracle.com, linux-kernel@vger.kernel.org Subject: [PATCH mm] kasan: avoid resetting aux_lock Date: Tue, 9 Jan 2024 23:12:34 +0100 Message-Id: <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 X-Migadu-Flow: FLOW_OUT X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1787652611738852379 X-GMAIL-MSGID: 1787652611738852379 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 Reviewed-by: Marco Elver 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)