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 8B72BC27C40 for ; Thu, 23 Nov 2023 02:31:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EAD586B062C; Wed, 22 Nov 2023 21:31:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E5EA16B062E; Wed, 22 Nov 2023 21:31:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D25F46B0633; Wed, 22 Nov 2023 21:31:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id C04B56B062C for ; Wed, 22 Nov 2023 21:31:04 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 924A61CC5B4 for ; Thu, 23 Nov 2023 02:31:04 +0000 (UTC) X-FDA: 81487641648.14.FEA30DC Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) by imf07.hostedemail.com (Postfix) with ESMTP id CCE5D40016 for ; Thu, 23 Nov 2023 02:31:02 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=mxT09MaK; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.216.54 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700706662; 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=U7iDnp8t+KdyeiUT7D88qTOqMxvRmmiP2r4q7q2VrCw=; b=LHoMjo5fc1JatL6oOT/foz/tF3TJB7gq5GFNWee4wWuIelCJHn4yOp+5/acUkbdnEDIT4C yBHvDc3tU2JPNvxlor033Knb3o82NVBklutnPpLBrrDarKVYhfVrAOwvLO9e/3zkqsBNVj IU0TLDCb1CDPnZgmDfigfKL8+NWXxTY= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=mxT09MaK; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.216.54 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700706662; a=rsa-sha256; cv=none; b=InQ/pc6T9ObUX4M+FWWOOFv61hJkm0VlnY6oJ0ULzndbzU6fEv9jueKXU5wid/t0+gHgOH ySViGCtVGzmhoOikAL4dG8d488wymDHyZ7CvjtS3pM0Cd0C7SEggHDgcrcVG836yCZOTrG 61idGOe9dbcsxW0Wn4zzEuHI6Pqcfdg= Received: by mail-pj1-f54.google.com with SMTP id 98e67ed59e1d1-28555b0c7afso391985a91.1 for ; Wed, 22 Nov 2023 18:31:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700706661; x=1701311461; 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=U7iDnp8t+KdyeiUT7D88qTOqMxvRmmiP2r4q7q2VrCw=; b=mxT09MaKEIH6fpb+zaw19WFdgJOjDEWcMp8URSVM26oPBe9Z2YRRQQzy1mbl4cFoHy s21qyxyrmEZ9F9fnUzU+ouLKCRBw1uhIIUBko3V03TMvpeU638NePeOsorlk4yH1Tjbt EW5xOkUizly0hdupClrmF/BYlw2v4ieUPbtT4n90C1Tma73a7BjOalDwPcAiFyzWShkg brZJ0lqRd82plYH4T53UBhQRJI8wsCS0fA+VferuG3BTQJJvUDHxNwZowH0owqdEDbPO EZGQ9zZ1KgZ/VNrz7AgmWc16EUsLVmyZtJvNc1iY89O8m9CFZqIUlIKJh3cERhsDgvTf modg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700706661; x=1701311461; 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=U7iDnp8t+KdyeiUT7D88qTOqMxvRmmiP2r4q7q2VrCw=; b=sTFAmeODa6VVwqxN+1MJY6Dqm6Wo0ozKx23yEgUc6ouAMcmdHNdZDFQKrs8zevofVR cF5wRuehyVbRnkAQhO9F2LXM7zAxaDqtSUfZJ9HwE5yCxUh7KHAD7xhcMREjIet48+mV fav3irZiP6q2dMD5h3WdjgphM5bt6hPOKb751tknPe2b8mJaj0v1rcZa4jns5I6PYUn8 1MQrP9qjsvoGmh8N1klagHIScUo7wx54EPsdBlgE1w8TkzXbQvt0V511XPw+UXvYeuEK IsP/UrD7sFvOtP0PWdfilI5BKzZeu3GwdEAI0ZaQQaYso2GZy3zi/F3enUSyIrKJLkfO mGgw== X-Gm-Message-State: AOJu0YxeaY40hyt8xRd95axg6XE9aP9wMEBqsWOuB6VYEuKYUdDGwZ2k TSkYsCObsGEudrEtH5M0+6ozDTI/gTx53rNCWL4= X-Google-Smtp-Source: AGHT+IGGFUweecO5epVQcB0JiJi7vITOIzmn9FsdMPNQTFuozzvhOm6PKx7gcT4Fo3Sa9N0+DlQ5wf+9MN5SXTQsCX8= X-Received: by 2002:a17:90b:4d05:b0:280:c0:9d3f with SMTP id mw5-20020a17090b4d0500b0028000c09d3fmr4312829pjb.34.1700706661646; Wed, 22 Nov 2023 18:31:01 -0800 (PST) MIME-Version: 1.0 References: <20231122231202.121277-1-andrey.konovalov@linux.dev> In-Reply-To: From: Andrey Konovalov Date: Thu, 23 Nov 2023 03:30:50 +0100 Message-ID: Subject: Re: [PATCH mm] slub, kasan: improve interaction of KASAN and slub_debug poisoning To: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: andrey.konovalov@linux.dev, Andrew Morton , Marco Elver , Alexander Potapenko , Dmitry Vyukov , Vlastimil Babka , kasan-dev@googlegroups.com, Evgenii Stepanov , Oscar Salvador , Feng Tang , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrey Konovalov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: CCE5D40016 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: x4o65mt3z7nwjytwhxgk5txd63xfw44o X-HE-Tag: 1700706662-935924 X-HE-Meta: U2FsdGVkX19BFPco+gsZksjs0veHOndetsYu78Mt5ci62vt+EGgpGOck58IJXbprkIeEwMclY7YqOHGfWtD0T/14XqhNFdJjk+OvzNhhe8dD5Cr3oCgvOSi53FypqWhdLoxXRo48kgQ6ufRp+H1srK33goV1+1voRn9Ka7XW+QMXjhcpgJEfgavZ9T97AimG/PuL7SKKANbR/7HyWu/b5RHUlinxxYMjWi7MbD2/iQmnssrKzRFuhXmU2xYPUbpgb/Vi0eB7mNQ346HVogSSayjXz58oKHGOUBiLPBHnZmayct3J6Yil6h/ovTnsavocjL//ejyoB1NmY0dFWtkw356EtRi9atPxv/kq+UMdafjANYxQ+VyUYU9SUj9x+Rr9tb5cIvqm7725yvUiSfCsL9RXBQbpxvbBrDyNylLLos8O+/6hOE/niKRM473gW6Fiqgx2ui09sxS92W3mlquCF3hVxb0LHvBpm+ueTvCHDtnc00DCNvWNtHNGfoXfCEHntqnhxu7JdmnZLG6OS7dwPw6BaoSvJFynBP9TU6eoCBomwtkcMVmhshX4cYmUiLBEsRbTVv/hZxuwv1wL1MUOK/2grUkYXR+Ai0nB9/dJmv896tReLw2iRjw4sfwFog5FfXQlwBwwcHdl8wD2DUTa3ndFOq65brhjJ2CHLyUNaZrJzNkMKwxM5plDHQux9HvHRRveVjxIfdTrhxnftcGKozCEUfn9JOFrLN4YGCSmV1T/M8Q44Tr7LahccDnhcgrt5xxAyRCWA+R73SlYkokU8gLKaWRDiQ1JwAkm5rFZbU8sIdmmb2Lv7gqrSS4CWW+88qsxPMk4zKJvl5KTTKIxxO4IYDQ3Det+hnxwrL8TM3JR+TbJGv2X1QkC342E4N7lLbWXayUrKhPvDwIFMTZMQ6lHx+uUhEUi8ecsMhwKne6iYsqrcDg+GpvgTu31L4iio/+koNhLpKTE5SiIMUO hxI0dgkk H7oM/POfF9PPDjbV0rZiX6iL906/4xZXYL+jZba+ew1LdkrXutAjFCwWUd4a7BrsGX46OAYLHMYwbGF3lv2SlKnEG4Lbb51nnB6vMTCNtaXiW6LyXa3NQf6D5SWS4hv4cEU4Nu+onHhjCIZmcEG/h0sDWhuybWrvptmI8kNb66qC6YobOgOgylAWx4SwJBOof1wJzdI5ZYrOE4MBvnlTVzXV3oP6+doktul/3KBM0qP7TGZsqH8WNoPPGxhfJpuaGrosu5h299Czkhc66PFHbvAr26FttjbA6lkXL5+Rjeblt1srMv+1P90WJtkBcR44/a9bMGM1Dz088IH+N5j1NxgW7EIF166VsEaQ/9DQ2SyYQvuAVCLL9PZMdrlU+tGoxDylEb2sKW2PvZkBicTKibIJbVqd9RsSV5Wr1bGPgC5jvq2UCpqXjNg6c6HizSJM9QNkBfM4WEK5gJFTiqpAo455Ucx+j48asj4rle4HODuTyb5eGdvHTCvmJa27bkhp2k5EVA8sFKtxwGJY= 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 Thu, Nov 23, 2023 at 1:39=E2=80=AFAM Hyeonggon Yoo <42.hyeyoo@gmail.com>= wrote: > > On Thu, Nov 23, 2023 at 8:12=E2=80=AFAM wrot= e: > > > > From: Andrey Konovalov > > > > When both KASAN and slub_debug are enabled, when a free object is being > > prepared in setup_object, slub_debug poisons the object data before KAS= AN > > initializes its per-object metadata. > > > > Right now, in setup_object, KASAN only initializes the alloc metadata, > > which is always stored outside of the object. slub_debug is aware of > > this and it skips poisoning and checking that memory area. > > > > However, with the following patch in this series, KASAN also starts > > initializing its free medata in setup_object. As this metadata might be > > stored within the object, this initialization might overwrite the > > slub_debug poisoning. This leads to slub_debug reports. > > > > Thus, skip checking slub_debug poisoning of the object data area that > > overlaps with the in-object KASAN free metadata. > > > > Also make slub_debug poisoning of tail kmalloc redzones more precise wh= en > > KASAN is enabled: slub_debug can still poison and check the tail kmallo= c > > allocation area that comes after the KASAN free metadata. > > > > Signed-off-by: Andrey Konovalov > > Thank you for looking at this quickly! > Unfortunately the problem isn't fixed yet with the patch. > > I applied this on top of linux-next and built a kernel with the same conf= ig, > it is still stuck at boot. Ah, this is caused by a buggy version of "kasan: improve free meta storage in Generic KASAN", which made its way into linux-next. Reverting that patch should fix the issue. My patch that you bisected to exposes the buggy behavior. Thanks!