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 877FBC5AD4C for ; Thu, 23 Nov 2023 16:12:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 202226B04F5; Thu, 23 Nov 2023 11:12:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1B10E6B04F6; Thu, 23 Nov 2023 11:12:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0A0596B04F9; Thu, 23 Nov 2023 11:12:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id ED9106B04F5 for ; Thu, 23 Nov 2023 11:12:22 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id BF8921A1405 for ; Thu, 23 Nov 2023 16:12:22 +0000 (UTC) X-FDA: 81489711324.09.55A26EF Received: from mail-qv1-f54.google.com (mail-qv1-f54.google.com [209.85.219.54]) by imf10.hostedemail.com (Postfix) with ESMTP id C955DC002A for ; Thu, 23 Nov 2023 16:12:20 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=gELOchIs; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf10.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.219.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=1700755940; 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=vGyQEtxcPZXDfK5MLunRkVEU0dG6NY5S9HKgUKbsr1Y=; b=IR0COWGURoo8eUqS2f8ssQgL+3OzYnduooKiMLECqidH94SOc95HnGUoUvGjBRHlQ/2r8b hnS2AM45gIVr+YAo9aDlg3mBBi8crtZIkgeZSwAOiTzvHHXfpSAkV3nF7FPtjTVBKQ7luN dTMWLOeizMQxx25Vq8iaVW9ow3e9zbU= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=gELOchIs; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf10.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.219.54 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700755940; a=rsa-sha256; cv=none; b=Sbbj83lhmJxMXKyS+w9hcJKA5xri+hNwMdV3nP6n2sNYUjkPJA5KMy1roiigRiWqZaaKOL eA4gHcIfcAgz9etjPPvCJukq8iToeAr5+pY7Izxs66pVf6NJhWmgm9h6zdhZSFWf+jgLnj RUmDmyHMrRBdxqviq3OqhXeSgimp/yw= Received: by mail-qv1-f54.google.com with SMTP id 6a1803df08f44-67a0dd02364so1778856d6.3 for ; Thu, 23 Nov 2023 08:12:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700755940; x=1701360740; 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=vGyQEtxcPZXDfK5MLunRkVEU0dG6NY5S9HKgUKbsr1Y=; b=gELOchIsi7CMBw8WPipZ30kNHWyehU/0CL1EM/wvzTZbnYC7AEL94cWNQFQ8vFCS5S Ts8WIMoFl98U94mqKUUd108LABj2AkivMVSsvA3b6hNWeE0iDziQepWomSxoIULF7dz7 GHRCMIQmfQcI/zMY6KlD4rCk+I/6OonUzD75GNGoI1HpCm1EveP5x3pW9EzB7mTF5vYr bQYcOuImAzOs+lGPnrfdMfSmf1NZNw30sGXik7oKC+/8qk2e9nYKGElUHvhqOZvhHSsP r/KKHvZiL2gKvwHuuWSG/Q0TYA9oQQYXTt4Q9mM+H5cLs8UWRRfTClr27xLbGtSSBROt O8CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700755940; x=1701360740; 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=vGyQEtxcPZXDfK5MLunRkVEU0dG6NY5S9HKgUKbsr1Y=; b=HR/Rr0L9HckLC+dKUgFb09lfjYs9oq5xeAz5xYkUFZKyYVk/JxxFFfxfu7/+kNx49q DS5YZliKCRlX9fXNLe797S3i3sD9MkXNEMEk3lPok9otOV3k0FakPETypITd7KaXz10N rq8PwX2slCueSTIpb+TloTnXC+yHVI0czvt6W9Zxxav7trE2G8WGr0Ya4Oy/zL4WQjcR GB4SlrkZG5fTz3BHV/ZDVy2xIyrEt31CVplsHVXK8Lmfr4DrF8jFn/oQJM3Upoaatp+j 75LeOe//SJhmDTvPTUKd0myax1YdqXGYzvodiKp/qAep2qa5YME1dZMNCQeOPXk8BYeW 4AQQ== X-Gm-Message-State: AOJu0YxbHW94rqaRqKSm86kxTBvA9amGoGWWih2b4pOZXYA/POkkesrh 1FzTIvGECAvd197OM9pldOuTmskOW/rWz/XkDUg= X-Google-Smtp-Source: AGHT+IFf92rQ7Iiv6WS+3q0acJTP9/j2IzOmmhqe6Em2KAoTKcA9LyHepmXhNDvx76jaLNiTaV6rjfAxwkYjqXRBPS0= X-Received: by 2002:a05:6214:21e2:b0:672:aecf:581a with SMTP id p2-20020a05621421e200b00672aecf581amr6478936qvj.47.1700755939932; Thu, 23 Nov 2023 08:12:19 -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 17:12:08 +0100 Message-ID: Subject: Re: [PATCH mm] slub, kasan: improve interaction of KASAN and slub_debug poisoning To: Feng Tang Cc: "andrey.konovalov@linux.dev" , Andrew Morton , Marco Elver , Alexander Potapenko , Dmitry Vyukov , Vlastimil Babka , "kasan-dev@googlegroups.com" , Evgenii Stepanov , Oscar Salvador , Hyeonggon Yoo <42.hyeyoo@gmail.com>, "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-Server: rspam09 X-Rspamd-Queue-Id: C955DC002A X-Stat-Signature: 9e9of3uremjjjqzqfhjxodczu5c4qabk X-Rspam-User: X-HE-Tag: 1700755940-415658 X-HE-Meta: U2FsdGVkX1/p/PmZSplChg0DK37ywAYGgrcISXG5U5htoHk7YAsoi4mm/qopvrboTFUTXeRR1krxF59QnAzEXYHU6qiXCLxvvTMjw8rj+sY6pp3xR5Gvee3jDKnKkKeBspnVmNSoKwYDj30DImj/uFp842oVrq9zurcuEr3UojAEIoPJMff2mMhhuHQwMyxxkUgV0btzYRH6wY73MSmxbLXjNJP9CWrfsxzPoM53UFhv05z8NEpGgcsGuTiTSeeShciFcSF8XE4BRqmnIjWZsmNGjIaV5yKUOfaR2bbMi7goFFF3sQDznrndAWfmI5IBlwkPcnKA+qbBYIKfOUDaqGCMdlIaVno/0Zno/+oAAcYlOAH+/0Bd25Q4+EFK0oYKECJ/KORvKC1LpiseBKlCqaS+P1HZArVZ0bf+Bmq3uI1rHV3rgxPNtKoRA6G2FdrAzFvnp75q98gji2EOa8+/kj4wd3I+CDjw/lwC4QcxeDnJ7WeSN/FSProita5QbjexnM8aoYumd+a/Oj8T0BcCLcp2Nz1jPh8JZtpSTaEwIIpm9l/soTcIK8EhuWgF/QyJz5XxyqtR3U4DCKt9Eel5VY5m0a680IjZeOMwU1kVHUynBP0lvPdwUsfX5hxmSDoUAInLWsBpj+XVnvCJNID5aG8zMAF5On7KzN8wkK2aw9Po8sMCELdjPSxMPCX0LLkW+OrBkxGK59oA6I0mLllNuz+MP3+xyeM4fV2DLJKgvlaL7KmYTpVBkdzqqVLROyL1fIqQvLTVZ91HLMh+juTnRyu5K/KiqVODHTNCYxR/FyDaqKoMzv7eyGcpw37EwnpzbI6Y6lFr+S73fpuZi+eKCzGE6MkraxpToDjOIGda6mbO0/Xu+E3QqYgBBSS8JQysJRzSMdEIk4dUSZeic5MtLdYxJ3mLWzo0dZNNyIkuOL0EPqZW1JHVEhZbhqbDYFAkfTZt1H2JZqjXFvMfgn9 xndZD8oC mJ8lPksqDgP7bIFzkdZF+BsFIcCixcqE/4XE/iIgWe4Y5KS5XLnfikNjpiPMjBhQfWT9JvGniiJJloPXncdpbwsKoPAM1n9aQ8VtfcV6CXiGKstIIcVttG4C10BFxPk50WM2Vz94ZHEX9VsaaJexO8PTWw+DW6KXcEgIH1BXHVixi3+9lZOUwKdhGc2ZeZdTAKU7BuzoAuToOg/jZ/EKN/BJNFIJJhLagAzd/m0y14OfsNA2Z6Ib18ZuEhjo0PvgT5WD4t49vALvGfQFUvtz9jTdkxLIdn8Dh/3vR8acWfE2Bv0elfHpMaCc31TLtBDPZpq2TRYZ620W8dnM4pGYFzShGRLsV/SoJAxxP5Tt/EieO6ps3tJJhjnSUNncW+oZxAAXmGrepqIUfAHhqBzGQyVbPs3SXyVVutB/9R5/I7nuN886Bm7rrAar3JbiXKFnAzWyAduss0v52H9rlsJ7i7IdpjHioMdTIY8+2TWar5N1XJOPHm8lIhPye2q/lgnbltBFRiEPhf5UQo4RQseIVmI6ESg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, 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 7:35=E2=80=AFAM Feng Tang wro= te: > Hi Feng, > > --- a/mm/slub.c > > +++ b/mm/slub.c > > @@ -870,20 +870,20 @@ static inline void set_orig_size(struct kmem_cach= e *s, > > void *object, unsigned int orig_size) > > { > > void *p =3D kasan_reset_tag(object); > > + unsigned int kasan_meta_size; > > > > if (!slub_debug_orig_size(s)) > > return; > > > > -#ifdef CONFIG_KASAN_GENERIC > > /* > > - * KASAN could save its free meta data in object's data area at > > - * offset 0, if the size is larger than 'orig_size', it will > > - * overlap the data redzone in [orig_size+1, object_size], and > > - * the check should be skipped. > > + * KASAN can save its free meta data inside of the object at offs= et 0. > > + * If this meta data size is larger than 'orig_size', it will ove= rlap > > + * the data redzone in [orig_size+1, object_size]. Thus, we adjus= t > > + * 'orig_size' to be as at least as big as KASAN's meta data. > > */ > > - if (kasan_metadata_size(s, true) > orig_size) > > - orig_size =3D s->object_size; > > -#endif > > + kasan_meta_size =3D kasan_metadata_size(s, true); > > + if (kasan_meta_size > orig_size) > > + orig_size =3D kasan_meta_size; > > 'orig_size' is to save the orignal request size for kmalloc object, > and its main purpose is to detect the memory wastage of kmalloc > objects, see commit 6edf2576a6cc "mm/slub: enable debugging memory > wasting of kmalloc" > > Setting "orig_size =3D s->object_size" was to skip the wastage check > and the redzone sanity check for this 'wasted space'. Yes, I get that. The point of my change was to allow slub_debug detecting overwrites in the [kasan_meta_size, object_size) range when KASAN stores its free meta in the [0, kasan_meta_size) range. If orig_size is set to object_size, writes to that area will not be detected. I also thought that using kasan_meta_size instead of object_size for orig_size might give the reader better understanding of the memory layout. > So it's better not to set 'kasan_meta_size' to orig_size. I don't have a strong preference here: slub_debug and KASAN are not really meant to be used together anyway. So if you prefer, I can revert this change and keep using object_size as before. > And from the below code, IIUC, the orig_size is not used in fixing > the boot problem found by Hyeonggon? No, this is a just a partially-related clean up. It just seemed natural to include it into the fix, as it also touches the code around a kasan_metadata_size call. Thanks!