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 220FCC47073 for ; Tue, 9 Jan 2024 22:36:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9935D6B0093; Tue, 9 Jan 2024 17:36:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 941578D0022; Tue, 9 Jan 2024 17:36:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7E34F8D0020; Tue, 9 Jan 2024 17:36:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 678A06B0093 for ; Tue, 9 Jan 2024 17:36:43 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 485BE1C11B0 for ; Tue, 9 Jan 2024 22:36:43 +0000 (UTC) X-FDA: 81661233486.18.B5B3304 Received: from mail-vk1-f170.google.com (mail-vk1-f170.google.com [209.85.221.170]) by imf28.hostedemail.com (Postfix) with ESMTP id 8F69DC0018 for ; Tue, 9 Jan 2024 22:36:41 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="Hzem/O52"; spf=pass (imf28.hostedemail.com: domain of elver@google.com designates 209.85.221.170 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704839801; 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=wkqH0kvhJZgtpeoRvV3BZL+94wcGjMIJhbLOpqO3e68=; b=HL14VQywjJYHYazygDrXb6zkB84eMLSPezZYM41f0vYdi5TU3wiE4K3glc0zU4+GVu+yyb JB+yLUy50Jz7UZIxf7ZVVQbQlNkcmTEaPjwUcKbJQETohoKzXhAQ9wQwnpl6L7S33OJRth YiIBfE1Nv4emJlyuP986agOZh6paYQc= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="Hzem/O52"; spf=pass (imf28.hostedemail.com: domain of elver@google.com designates 209.85.221.170 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704839801; a=rsa-sha256; cv=none; b=BPCMRKTxFwkDxh1mKFt1Sji35XAlrOUpOfQaEH6GrYfGG3uBC1CQtxvuYBKUnJABGoDjD7 8ACRcllcRBfnzZthfYWTwfypyPm0Xg7JbMpfKtkUdVBCLpzzRDUP/o0hK2I0QNb+xqY3hh UUCjmgH3TDtTIJLqlR68FfEt3wqbKrE= Received: by mail-vk1-f170.google.com with SMTP id 71dfb90a1353d-4b72e63821eso2540077e0c.1 for ; Tue, 09 Jan 2024 14:36:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1704839800; x=1705444600; 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=wkqH0kvhJZgtpeoRvV3BZL+94wcGjMIJhbLOpqO3e68=; b=Hzem/O52AZy9ZfIa/U5yNoAYIglwWXBDxRq4DC8Tezi16GEgc/ZwMj3VzFM8TiL9uA QoBb0AxrTkHt1d2cKWCsLG38vcFh2nh4+iP/zTa2tsM5VfdeY+nGXsUFxN3oqiHhNFW1 4Cd2H5vQWGDr8H98PHCsk2wUfC0sOddBwxOArCv4YwtP7VvwvU2yPfY94Qp/bquC2zEe ezpZeTk1YX7gmj6ecA1OxNfjurL1aCR7fwSdDHLcS6hS/4HGMDd692VHoqb8IaX7Uqi6 AdBx56v5W3XXLIznVGjVDnKq+cABj8PvCqZ5hRkTmKbwaeojnweR7RRJodpkIU+T36pd jJPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704839800; x=1705444600; 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=wkqH0kvhJZgtpeoRvV3BZL+94wcGjMIJhbLOpqO3e68=; b=vJHPCdxbIP/u9wYkWbiDK4f+8cpIhAlVier8FtbV6dPeTU5/7r8N5sjC2+aoewPR9I W6llv91vp/Dx+DiPHU7Wg7rpIg9+QM8nLiPXnnOyClI7UhkiFkKoA9l71+Cxn2fRxZFj HMfW79uto+UNm9P4p/7tsG/n1Ul61uiefHC6smdrIdDcxN4w1diFi6JwbHy/bWyvPeNa pyyUkRXmXn4+jh0BuqDrnqnajQrZlcTfaaqhTap1rGoQtiuiov0mLgSA+D2v5B+UNCVp 7UEdV8cwQNV13TdVShfjSN11GZFNZ1De44zJws10tZpxNlTuxoEFMfOC416Qriebm2iP EINQ== X-Gm-Message-State: AOJu0YyWN1EbG8pCt8WCOk1esouhytTpPwfzz4wmhcgXq7VNoRjTqZpl LQI3nxCKq1T3RCUp18LJuBgnVnC4NshUQYeRPU6eangDUivg X-Google-Smtp-Source: AGHT+IFECzmkLvfxrqZ0QdatYe2GventwvLCaluPFt7FZ6mP5qF51G87ZKLIGTpMNa6ivHh0xrvU2idK4W63ISnwyYg= X-Received: by 2002:a05:6122:2a0e:b0:4b2:c554:ccfe with SMTP id fw14-20020a0561222a0e00b004b2c554ccfemr156571vkb.10.1704839800511; Tue, 09 Jan 2024 14:36:40 -0800 (PST) MIME-Version: 1.0 References: <20240109221234.90929-1-andrey.konovalov@linux.dev> In-Reply-To: <20240109221234.90929-1-andrey.konovalov@linux.dev> From: Marco Elver Date: Tue, 9 Jan 2024 23:36:01 +0100 Message-ID: Subject: Re: [PATCH mm] kasan: avoid resetting aux_lock To: andrey.konovalov@linux.dev Cc: Andrew Morton , Andrey Konovalov , 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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 8F69DC0018 X-Rspam-User: X-Stat-Signature: rixc6uximd9ezr6pw5mhd1ipg8ywfwnf X-Rspamd-Server: rspam01 X-HE-Tag: 1704839801-308608 X-HE-Meta: U2FsdGVkX1/ziBZp2voNaF/ccFLEKc1AA70Ji7PVgZvUNE+8gtsUEa2jexEUVZeZKiQ+9MzjOIBC+Zl7lQsXY8igtHoZm06sTFkpn2woPZWcAbhWP/6EuG7d4IqR0Qc1z8DxkK2dnWVRmlU4feTxJBaNNsPwsgSdSSfJzvDXzwz0YWWzmlYULv5bsUAL1ilXL3wVZwarwx+2eFQ4gRr7spHm7U2AguRLNgUW39f5DV+rufQp16W2wkGN4yJAEq4kfTHszzdsYRx9XECSWYPhmgKUvPLg/x2YfRix+H2ARrL19l1SL88k5mjGwm/UMrudjt0kdYd6hr7qryScom9djrY+qsOJFwazshuDK8ALPpGT4LQ+FCkJt7ShXuMzAwCWOV2b7jO2W5wE/cpvp/ZF9O6z8nUGFkij8C6TWkbyTKgLRBlKrgo73iDIODys/gC7b7NgCe6MQPov0xTI4zg6C0VjhJ51fqUFEIo9EpsXvASM4nMNRQbLPNptxDu5I6WP64MOG9JE7P9ZbqzDzyVPQ9HUUjszMxv8wANx4Gze1kgf9h+XsG2FqCgb/jhlJLDQ+71uHxasVuaHJvawM9PdKX9g5zyZc+gZo3E+05m5npYzwG0TyB5rQshlognmw3IqszYAXui7UoMniksT5atQeMYeErN7T2z81e2sF91TcrsfdDIa8N2jgvOK3eN39e62Y9zZMF8GFwlgC9S3r/u7g7LEy0TjZ35NT04AX6Xm8PBzyC7JH3jy9kypKY5gPDWJ2EbhAUe81IwUx8smj5eBrlvf/E2ZpOsYbISyCNOfTzyFC9lhnBWyVSWF+w1Z7Iq2tXFCjKmCVdXupXwknWeEryNqvpMs/YjLtQP9/fnfQtm50WYaBEi0A3vicN6qsnQ6Jnzs1812m/UVy9GFpB1mUi5SfMOGJgdfLWRNY4pgh/xb34S3LMNP5M3HWUJjrTZrWChHVEthnDzCbpufIlN Lon7s8uw ZORf4lGTbMVf7bFBBlRoOzzEP1mmRuY7VlLhHjkQikQanY6YUiY8B+W3aJbTa/zk14Psw3DdCW3PiK2UaQSVUZrWIScVDtvPMjtbf1rIC2WACKUivT2TKE77cHXU6yxvkMq5AIfsKFc5d0eZeWSoCDTcITHBl00aUTqTntgNrMi+WMXhnRLvTSlQRh1eeI4GHvIhvogKQWlJowABLquS7KjnV4ziDSJGbVnX/ULnSa0pMd9h8l1PNoEOkKsTyD6Wnmu4XMWSiQh/fXEINVeuBFxSmT8SpB5VyXs3NxnC/22k7VMncfBNc7w6ag2VGRH78li1vLiu3+t4RjlvPWCiHoS958Atl5+80zmneZy0Zw0/h3jK3cgrZ0AT5xcTSWqPt4HDW1kFiNu4N/8GfYMV3qWw5s/glrflA8597hgc5Tr1FAIMru65xg80+E+3iywy0qYww 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 Tue, 9 Jan 2024 at 23:12, 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 Reviewed-by: Marco Elver > --- > 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 >