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 DBE1EC636CC for ; Wed, 15 Feb 2023 10:03:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 763C56B007D; Wed, 15 Feb 2023 05:03:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 713BE6B0080; Wed, 15 Feb 2023 05:03:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5B51B6B0081; Wed, 15 Feb 2023 05:03:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 4B5F56B007D for ; Wed, 15 Feb 2023 05:03:35 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 14567C1486 for ; Wed, 15 Feb 2023 10:03:35 +0000 (UTC) X-FDA: 80469089190.23.CBC021D Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) by imf23.hostedemail.com (Postfix) with ESMTP id 158E114001E for ; Wed, 15 Feb 2023 10:03:31 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Xe685pvL; spf=pass (imf23.hostedemail.com: domain of jqqlijiazi@gmail.com designates 209.85.216.42 as permitted sender) smtp.mailfrom=jqqlijiazi@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676455412; 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=YRY/QGNXp4X1OL8xgNxCb7uWXA+X8wBiaGwcFoGIasM=; b=4R2LyZiebAg0iCCz2b4hz/8/LZiUDu0er8tLXxkkd1sVEBpqQm8/egfp+il+ZXfSk6OYgB Kyx/vXfyo+2Yhdw+JcZFzIaxqkw5yupimON+qyO2YRXdArVA0eXdZFtoKp4zWDkAF5UclI rbfias8gFozVFdHP9ZRTA9FyQw8LHFE= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Xe685pvL; spf=pass (imf23.hostedemail.com: domain of jqqlijiazi@gmail.com designates 209.85.216.42 as permitted sender) smtp.mailfrom=jqqlijiazi@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676455412; a=rsa-sha256; cv=none; b=UVuLk5eTbdsnqcLybhRcuNZ1HofZYJnWYH5lqLJLA4dIAlwKv1KQC0HxpyY/0HC9cgRWSE B/07rpYacelH4zD1kGfvb/QgwlSrvh0pLu/+kiOV+D9fgIYcibBclsIRAuky/BeLdWgcYr Sz2ls4dwoc1M4+98Fo38aeC+vT3d+UE= Received: by mail-pj1-f42.google.com with SMTP id o13so17717035pjg.2 for ; Wed, 15 Feb 2023 02:03:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=YRY/QGNXp4X1OL8xgNxCb7uWXA+X8wBiaGwcFoGIasM=; b=Xe685pvLVItZsFKsShJBDXiqZKWHo0cpq/zVwtDk9rs1vFdRlXsJqz+zNnKXBONdk0 t95V6ORXWEKqU9nO57lrpiZBtOmg/1VXGtfdtXleF5SU+oIJ+hyTZre1gEFCJ73OJrPU qeSKVyta4SfPxPIBg8E3CMvujA5YAeExCwgIi/U0Yg9WGEX6JDMKApC2k8J8wCpd5FVe 0y68/tUxHumkUvMKZmD6TwF470CophZA3MvwF+qefcnTIfJiZOIk70cA99kI76CnIyD7 xgzqnqsjadLFE0/eqoEQTXRRZTVLlTniOdTNvv0Eesc+kIVcicaDwJhSPNd32exnAko/ 5UeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=YRY/QGNXp4X1OL8xgNxCb7uWXA+X8wBiaGwcFoGIasM=; b=XfEhvz5D4MJeL2OApk4ABFQym6N4RiObRajSF5trWkDsmttDCjkyS9JUM+CP1uuKR/ ZHIx9Qug5MJrNc9zPY29Q7UhmTVPuijnxBoDL8K/iwt8NrhwSlEXR5fxhPeXTTsqapjw GReYTyYvfEivrGqeyTn1NNFbDmPpETK8pUkF+mTas3U5Ph/NC38CPXCC6KP+rXsgh5ed hnY9qv2I4hIky0EdQVw0cAMnkTxDhMsLo9+6K0PyrU6tia0rsBzqX2rtLeT9FOMHixIn XnyNdU44QwGf5qUF5i40jaFxw2ttPfbN0P1e0Yfl9Njess4APqasAbOF8kYK2A/HkTPT GoiA== X-Gm-Message-State: AO0yUKWhmTho35jPOC2LUNA7AiX7b0s/UR5s0g58mj73nuv/wNZyD1Yd KIsKfT851pzvSWHoOp2zWWo= X-Google-Smtp-Source: AK7set+ofMfLycAUI87OA9i4ajNRuYIKCqR6/aj+0MbH4bO3WebqsRQe1RKWZAdFXSYGwHx2yUWcCw== X-Received: by 2002:a17:90b:1e0a:b0:22b:eb46:7d2 with SMTP id pg10-20020a17090b1e0a00b0022beb4607d2mr2022077pjb.47.1676455410880; Wed, 15 Feb 2023 02:03:30 -0800 (PST) Received: from localhost ([58.34.94.196]) by smtp.gmail.com with ESMTPSA id ce13-20020a17090aff0d00b002310ed024adsm1098040pjb.12.2023.02.15.02.03.30 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 15 Feb 2023 02:03:30 -0800 (PST) Date: Wed, 15 Feb 2023 18:03:27 +0800 From: lijiazi To: Vlastimil Babka Cc: Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, "Jiazi.Li" , linux-mm@kvack.org, Kees Cook , Kernel Hardening Subject: Re: [PATCH] mm/slab: always use cache from obj Message-ID: <20230215100327.GA12544@Jiazi.Li> References: <20230214101949.7461-1-jiazi.li@transsion.com> <20230215053748.GA11780@Jiazi.Li> <884f051f-d1ed-756f-aef3-6ed3005de090@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <884f051f-d1ed-756f-aef3-6ed3005de090@suse.cz> User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: 1pt9kb7ryqgayb5o57688ktzui4opyjo X-Rspamd-Queue-Id: 158E114001E X-HE-Tag: 1676455411-867834 X-HE-Meta: U2FsdGVkX1/n0T+iPdlagE3EBSgo8v/Pv8qy9/rZTQY2MOoOz+WZW+YI8Fuol1/J7j4iFWgEeGf6aPlpcTKw8dOBqhRpCm5UWKycWj1q7MbV5xbgRSbGkS4NfMzvx60gmHBLdtN4vHTGEqt7BOP2Lp+DJDV7kUGeNzEV7YsznxPcUWosxX5GZOzR1Ha/PrHqdsbB0nfWwNud5ilbWzd0n86i9VUYLFMJUU3RJFgYJ9FmJGbwlKJuSdl2a2gDS4XoThfasSulp2x8Z5ksn6l4pzSmBNEXbfcErO0feVdo8YhEjDMDT39XbH/mgsVEJwbvR5uGozArXJgdB0+bh7Iy7429UrefUN7GIt5GEGgueVwmsCFo4VSYrdhOzeokBygvN8U8vWcITWWahXDLf9uX8oPSP98HF8OKr+s0FFOrknak1PO8hPJsMhNq2TXZ9KrKaFPGfh6JFrMgw0uNGBAO4rYjeJKg49Nt2+2Fr8ZYjKIwvNh6koYIQemkelgbLEWue+j0I836NSRPZ/v+netkLnZd+r1kNY00Z9jbcM/OfA5hLD5Z6kTlU5YBzqA+CKy0/JRv7qnaLD5Fcno0Mfxq0xhQtYIuPAwuMC9QOdwC5cejkaR9yOF7uFhA4w5J8kPK4GCUDwkg0S3SyJCJCgIxPxBpKGViIcuFSTQbH6qEj27mL1h4f2sNFyX5adW5tLe+X1YBjEDC8oJX1uNl0xFcUd7jkt2/R0kzoDL+HM4SG8lotd9UZdWYSVgcPt3naQVhgIdeLRbM0PcyfjXxALjJfidQ5OCrg8aP4pvrxP5GUo8LjxCEN4NLioZ8RquX9WYvC6LCkyyuTDegXZPPcyrV+Et9t7ee+xfJgH8AJazfD9sp3IwImPVsg4iH/ub0lyOyHptnOU09t5DEZFb3PQ+SVLjKRghf+dG9ThajBzfAK0Ur+dxB0WetOvvm8sdxJ47SvERh0bxaRUZzSxDtcnc LvIs4IWv nfB8NTzyqjw6I4m18krLZfBIWThmkaIjswFgl0ekxt3hDaWY8BeaIJ8eUfCBLP4R8N/Yi8PZ5GgYQk7r0oCSLZuJO8BSNSSbXJRaE3jgwt1OuB+Gni/DqqdyweC9p5shiiUxsqAGporj7m8fA8oJyxpZPoul/FrHvNu+s2CHRkPyVMQPNBoNXA2qmqV/bMyOLnWEKVjhe54K0bKl8KhD5Nq74LhpqhmlGF8LWRgMGx8ZIAXwQSGYlJm3DVXDe90usw1yczoj+mFDPAvhY9TbtGDXO78awPz3iQwdgLma3++sZqBReJbJBSPFhkHtAYBx1pUoIgsQtkuaLFmyPdAMZvFTm08Xu7tSGpgh5Z/f3X347wgMhA1aZv5B4fftb0pMyDWE0aGk/wN77GV1oYd3jW6BnfdiY2bpLvKfp8P0jTK+ihsaKThs+8MzUqKyi45+y5BuTkGF49CU1c66Tf7TPVu7pvdKekPl6xz/nBAZGi5KlixvePPs15WjZsfydxtbE7Jv9heWqkbCBz2/uyzrQAzLIzfXQQatFMHfTn4L7gVBtxx3rqullBf110eqSk5WZwaHNpWS4DJd9ZTo= 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: On Wed, Feb 15, 2023 at 10:41:32AM +0100, Vlastimil Babka wrote: > On 2/15/23 06:49, lijiazi wrote: > > On Tue, Feb 14, 2023 at 11:33:21AM +0100, Vlastimil Babka wrote: > >> On 2/14/23 11:19, Jiazi.Li wrote: > >> > If free obj to a wrong cache, in addition random, different offset > >> > and object_size will also cause problems: > >> > 1. The offset of a cache with a ctor is not zero, free an object from > >> > this cache to cache with offset zero, will write next freepointer to > >> > wrong location, resulting in confusion of freelist. > >> > >> Kernels hardened against freelist corruption will enable > >> CONFIG_SLAB_FREELIST_HARDENED, so that's already covered, no? > >> > > Yes, HARDENED already covered. > >> > 2. If wrong cache want init on free, and cache->object_size is large > >> > than obj size, which may lead to overwrite issue. > >> > >> In general, being defensive against usage errors is part of either hardening > >> or debugging, which is what the existing code takes into account. > >> > > My consideration is for the wrong cache problem on version without > > HARDENED or debugging, it is likely to cause kernel panic, and such > > problem is difficult to analyze on non-debug version. > > When reproducing this problem on debug version, it will not cause kernel > > panic, but only print the WARN log, then use correct cache to free obj. > > Because we want to reproduce kernel panic problem, so may ignore WARN > > log and think that can not reproduce problem on debug version. > > If you need the panic in order to e.g. capture a crash dump, you could > enable slab debugging and boot with panic_on_warn to make the WARN result in > panic. > Thank you for your suggestion. I used to think that the debug version has less tolerance for errors than non-debug version, so I didn't add panic_on_warn. > > Thanks for your reply, I will enable CONFIG_SLAB_FREELIST_HARDENED on > > non-debug version later. > >> > Compared with adding a lot of if-else, it may be better to use obj's > >> > cache directly. > >> > > >> > Signed-off-by: Jiazi.Li > >> > --- > >> > mm/slab.h | 4 ---- > >> > 1 file changed, 4 deletions(-) > >> > > >> > diff --git a/mm/slab.h b/mm/slab.h > >> > index 63fb4c00d529..ed39b2e4f27b 100644 > >> > --- a/mm/slab.h > >> > +++ b/mm/slab.h > >> > @@ -670,10 +670,6 @@ static inline struct kmem_cache *cache_from_obj(struct kmem_cache *s, void *x) > >> > { > >> > struct kmem_cache *cachep; > >> > > >> > - if (!IS_ENABLED(CONFIG_SLAB_FREELIST_HARDENED) && > >> > - !kmem_cache_debug_flags(s, SLAB_CONSISTENCY_CHECKS)) > >> > - return s; > >> > - > >> > cachep = virt_to_cache(x); > >> > if (WARN(cachep && cachep != s, > >> > "%s: Wrong slab cache. %s but object is from %s\n", > >> >