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 1FE9EC4167B for ; Mon, 30 Oct 2023 06:29:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4F0386B0170; Mon, 30 Oct 2023 02:29:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 477576B0171; Mon, 30 Oct 2023 02:29:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 318A36B0183; Mon, 30 Oct 2023 02:29:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 1EF036B0170 for ; Mon, 30 Oct 2023 02:29:28 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id DFE94140402 for ; Mon, 30 Oct 2023 06:29:27 +0000 (UTC) X-FDA: 81401151174.21.103F18D Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) by imf27.hostedemail.com (Postfix) with ESMTP id 05C104000E for ; Mon, 30 Oct 2023 06:29:25 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=obR1oa5g; spf=pass (imf27.hostedemail.com: domain of dvyukov@google.com designates 209.85.167.41 as permitted sender) smtp.mailfrom=dvyukov@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=1698647366; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=rzVHmjEI+YpEe4gZLECBFUB4/fthvdQpMU6WpBuzUV0=; b=lWLsI4PwIe8wqdMazWaeNRfAEtuM8Dqg7JsctpeGlEQIwP1UZxY8hWrgC2hB1k00u/Plhv r7PvsA4HuU8X3HLipKoHrpxnZGJXZXdnwdhi6Fv7q4Kng5wXAaAmsYGOqP1iyr0tgX7tfp WzIAmRHB5yrrc449tTR1mIke46gQrS0= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=obR1oa5g; spf=pass (imf27.hostedemail.com: domain of dvyukov@google.com designates 209.85.167.41 as permitted sender) smtp.mailfrom=dvyukov@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698647366; a=rsa-sha256; cv=none; b=F297fnmPCaspyao9qpgyMcT0Kt45NHrTtvRAJEWaHwMIse4vQG9hCiFY+2xh03hHCdr38F rSLINuHrPt9vf/GqgKygQPkJvF05M+Y2ENg8Ul/XIHX6Bc0p+xAOHCyzIpnoE5bw8/rCx9 KWP9oEzJ6w+96YgN5ZfTphBT+mC+f7c= Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-507a5edc2ebso3626e87.1 for ; Sun, 29 Oct 2023 23:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1698647364; x=1699252164; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=rzVHmjEI+YpEe4gZLECBFUB4/fthvdQpMU6WpBuzUV0=; b=obR1oa5gumuQVQgdof2SbNR0yeK7z7BnGO3SAM16nSQFZ5/J5j8nkTN/XZJK2FGyHe iAltXjP4avl9AfgMz0/Up0Gl6VqCEIy5qhXf4zvvSoxDkKJAPQO1De1NEOTkUON/vc// rDNQ1IEJEgSDdx32aGbZg88zbGnb7LXC2WvVgI8lrnwegwekjdZ8SsjgoKpHWGtTqggF ajcWrrhLXoVY2arw5WLdIJ2NQm6Gx5vlUpf/oS3fAGRuRbzfcafn96Bd9927JuSggQfd hf7hIwDns9geQZd8WcKN6caWMtsDCboo5RYxt+y+FoBAOPAmubrqeRPg1W+qNRAy/FlI 7jNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698647364; x=1699252164; h=content-transfer-encoding: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=rzVHmjEI+YpEe4gZLECBFUB4/fthvdQpMU6WpBuzUV0=; b=LR1udllCBpN2p/vLVEJ0EnysREdTOJ2NhUbrX0dI5wKt/36wPwvdmkdII3/W1wCgf3 lV5R7lg5oNAUjHPjUi/nwH/MTqbSr+geIun5FMLcSjA2C3tXX90aMSPsk62yceY0+s3l 9Bpa/drtFlAyIH1VDebbTrChDLLWpHL9L1NYLbdlDytCwy1BUomedIq2H2XlAfVWzQ6h f4ul2d3TH0Dhf+SWfBb3qczgPJSVrwHu/88TPuUHvwiJOjUEiiwRX6CdW+J5Hebc213Y m+bnBFt15ilGt8rKPNRt48cR0jC5AYxXDyhzfnZQjYe31D95ec9NQenYhngJDsIW9LAQ lKQg== X-Gm-Message-State: AOJu0Yy0IEcBWlIvj7o2vwV0JbYY+RK+XaC12oEtkvVJvQCEadMZ/bMc ZRYYh57yDJCYGoI4q3PXrMS7dbgJiMbFBf1NLvAfTQ== X-Google-Smtp-Source: AGHT+IGNd8Zyh1SuuCCalJuqfkJij1W8Z950z1DL0BW7grGmSYMkrmd9YuoBi5W65KCG6eZKQxoa4NdSsGzWynyaMVE= X-Received: by 2002:ac2:4e85:0:b0:501:b029:1a47 with SMTP id o5-20020ac24e85000000b00501b0291a47mr58180lfr.1.1698647363870; Sun, 29 Oct 2023 23:29:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dmitry Vyukov Date: Mon, 30 Oct 2023 07:29:10 +0100 Message-ID: Subject: Re: [RFC] mm/kasan: Add Allocation, Free, Error timestamps to KASAN report To: Juntong Deng Cc: Andrey Konovalov , ryabinin.a.a@gmail.com, glider@google.com, vincenzo.frascino@arm.com, akpm@linux-foundation.org, kasan-dev@googlegroups.com, linux-mm@kvack.org, "linux-kernel@vger.kernel.org" , "linux-kernel-mentees@lists.linuxfoundation.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 05C104000E X-Rspam-User: X-Stat-Signature: 961q3qme6ayf85g5se7hmb5igeb9negf X-Rspamd-Server: rspam01 X-HE-Tag: 1698647365-76905 X-HE-Meta: U2FsdGVkX1+JvIwvK246sKATvz2KADlUgDLFhlaMwGh7eqCbmFFQ08kz/ivWK6PLYa38ErkfYrA8E2p2mzhawhHYqkkOD1F7ZAy1HCti1CarZXHUY2UeCkNm7r31KTSnSmNKCyn0lSf/UbuheeLi1cuSZAGAnOsHuhwNnOaRcLCwjkQTzxrUWzCSLPgCWQm2hbMY/tremxCVQhpFCy/I5vqzRU2OlUomzf1et6xaqFbsZhCOvG7hkus5LZ6a/hNoHBxGovJ8IdLtIQI+TpqQPJNmwfRwlx8PInJakTKrM56nrzrw+My01ryLfhmKDtlSUbURcVtcDFIcUohUmDJobsvgXg7GuCghn98fkPs2wx0ZwhHCCmxQjOWtX3z0aYOjDr3afJcmmLHHD19Vc4Gy9l5/WTUlEpySXkrJzp4ygenfGA/d9HmJEuFMjRekaq2PKfJ4o0GccLfOsgjp/GEMiBdDkPzBhNNgKqKB5JzrN2i37/AbdeM38nwpScnHX65PuDKnEvgGFAf5xdP+oBwOWvO2XpkLLRn+U8e5Z3IwCrIo7yIeHTIGcVGrZplPbqBz5i/hW2VNrKuiaShlikLpTYqIPlYAAcesB/2ea3xN7IwxAf/uFXs/6ICm+A/7P/CyZ4I+uL8Kf82nUOzEG9UAj8HyKTE8QP/prA2lIi1hJJ84Ig40pUuQVeRX9SplOjqZqYaR8tb0DpL1H6HG/H6oE56WAmAuf2doFGPKwuf7tXAw2SYa4bEMvvV4LBaJ/Ye0cjCkEUHpExrJOLndAQqTNIvGerpWNPJfM1XReyMFAvw9nXPoW5QYSlFq8EyVMePOynYaG3GTrFNtcH0MnSXcGbPg5KuI+5SKad4ZlqIW/xoVNGFeurnBP2W4Bn/lFfNN7ATUFu9yGdYfxQxVSetGGRAyBwBg897zBxyAmeXgoesFIcOLxfqrqtG95hDXIg3WJ7tJMF1HbdBp4vhKGw9 tIo44U9m Ac7SQtkHFrSO3xe2ADi94Hc5SWExKQ2xbT9+L6eqHzYQVV6AKNBTs7t7ABV3RJ7/LMST0InE5+UXQY3jUzv0M8NqFEgOTyoZ0A82CMVcy0HZX3wlYFeZ9sefO3BOnNofbC/SJ2KIFD9syVVxoeB4FCzDqVsIQZDgIrvPh3X9EqTQbTgiYr5jEI1LxJPiW7cZl3asRBullTwbKnyPeV9q30nIVJtOshRTd6hk5P5X7cIpuwBMS/Q8gDueoApkCR70NP1+u6GIP9WbRZfReGrCiaqbrrq34U8K/u++HKHXV0coNsXgQGxH3Fc8iqyEcMAGCECr8l/zn+M1nrJg= X-Bogosity: Ham, tests=bogofilter, spamicity=0.033922, 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 Sun, 29 Oct 2023 at 10:05, Juntong Deng wrote= : > > On 2023/10/26 3:22, Andrey Konovalov wrote: > > On Tue, Oct 17, 2023 at 9:40=E2=80=AFPM Juntong Deng wrote: > >> > >> The idea came from the bug I was fixing recently, > >> 'KASAN: slab-use-after-free Read in tls_encrypt_done'. > >> > >> This bug is caused by subtle race condition, where the data structure > >> is freed early on another CPU, resulting in use-after-free. > >> > >> Like this bug, some of the use-after-free bugs are caused by race > >> condition, but it is not easy to quickly conclude that the cause of th= e > >> use-after-free is race condition if only looking at the stack trace. > >> > >> I did not think this use-after-free was caused by race condition at th= e > >> beginning, it took me some time to read the source code carefully and > >> think about it to determine that it was caused by race condition. > >> > >> By adding timestamps for Allocation, Free, and Error to the KASAN > >> report, it will be much easier to determine if use-after-free is > >> caused by race condition. > > > > An alternative would be to add the CPU number to the alloc/free stack > > traces. Something like: > > > > Allocated by task 42 on CPU 2: > > (stack trace) > > > > The bad access stack trace already prints the CPU number. > > Yes, that is a great idea and the CPU number would help a lot. > > But I think the CPU number cannot completely replace the free timestamp, > because some freeing really should be done at another CPU. > > We need the free timestamp to help us distinguish whether it was freed > a long time ago or whether it was caused to be freed during the > current operation. > > I think both the CPU number and the timestamp should be displayed, more > information would help us find the real cause of the error faster. > > Should I implement these features? Hi Juntong, There is also an aspect of memory consumption. KASAN headers increase the size of every heap object. So we tried to keep them as compact as possible. At some point CPU numbers and timestamps (IIRC) were already part of the header, but we removed them to shrink the header to 16 bytes. PID gives a good approximation of potential races. I usually look at PIDs to understand if it's a "plain old single-threaded use-after-free", or free and access happened in different threads. Re timestamps, I see you referenced a syzbot report. With syzkaller most timestamps will be very close even for non-racing case. So if this is added, this should be added at least under a separate config. If you are looking for potential KASAN improvements, here is a good list: https://bugzilla.kernel.org/buglist.cgi?bug_status=3D__open__&component=3DS= anitizers&list_id=3D1134168&product=3DMemory%20Management