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 1A504C636CC for ; Wed, 15 Feb 2023 05:50:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 64CA36B0072; Wed, 15 Feb 2023 00:49:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5FC9C6B0073; Wed, 15 Feb 2023 00:49:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4C54F6B0074; Wed, 15 Feb 2023 00:49:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 3D5E46B0072 for ; Wed, 15 Feb 2023 00:49:59 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 07EAEC12CE for ; Wed, 15 Feb 2023 05:49:59 +0000 (UTC) X-FDA: 80468450118.14.965F7A8 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) by imf22.hostedemail.com (Postfix) with ESMTP id 187E9C0136 for ; Wed, 15 Feb 2023 05:49:56 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=MrRLtD2C; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of jqqlijiazi@gmail.com designates 209.85.214.179 as permitted sender) smtp.mailfrom=jqqlijiazi@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676440197; 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=Cfjyb6YgPsA07U5Gf28JYt2DM3rLGD4qk8TtTKhzCcE=; b=saZsm9rUYYZY1Z7gl4rR30/dLGi5+pDDBL34ODPyqL2C1wJd7GWPnRvJP3pjBnbbz73QUk pl7UWdRq+ry8XbPieRK5iP+1x+5N8o4W1F1HLp2gHnC+LY6euWjJ+SjEZcpZzUiOwlm6g4 IDDJ2v+8dDt+bQtrVhWZiiYaHs+H9Vs= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=MrRLtD2C; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of jqqlijiazi@gmail.com designates 209.85.214.179 as permitted sender) smtp.mailfrom=jqqlijiazi@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676440197; a=rsa-sha256; cv=none; b=33DEe4jQzWUb0+o5l6yKSuBHXPmstApxFqZZpBwnGbHyr4XjtQckIYETb33Bd8t/vlYZbt yjHBj+l7LJ2F8DlYURVks6MttHVsY1eUnHMwsoXUGiK2vB6IajDmObhf7qZDZQSfgYCAFc kgnwrCLYNx/4rqIWG5+b4JSRlY1z6/g= Received: by mail-pl1-f179.google.com with SMTP id o8so16888667pls.11 for ; Tue, 14 Feb 2023 21:49:56 -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=Cfjyb6YgPsA07U5Gf28JYt2DM3rLGD4qk8TtTKhzCcE=; b=MrRLtD2Cw4ZuAEMf6+lkO+XmQ1dV0uOFwWHkFEsE2oO/HUPZTry5l3p0XhQOD91JP6 D4HN6TVn8A05ndtd0ZD3DsA5NNYFykmw1t9fCudUvQGvNSdpAZlXUmntBDZFkr4CfkHy rJzqNjMZGIkGGLVe2OICz/3AdsV69AikgwFGaPkVCyXriLssX96dm/C+vZUTT0HhRe8D Vy3XTRv6tgy1II1mDr8pyKPxARgrlLsQJjzxv9h4YUWvve0XSNO+NBO3BGXAs/4orbhi S5SfmghiKGwNrvd2R3RhborPxoAT62EkRr5qRKtspIGwE8/tLhaye+COP/PJ+1m7BkT4 f2Tg== 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=Cfjyb6YgPsA07U5Gf28JYt2DM3rLGD4qk8TtTKhzCcE=; b=iBLFrJppzz9a2j10YXnG8rqOc4dTjcJBHDxrzoUBrXw7lhQETPoIAoDkLg4esyi9BA 9XH+K1Kf/Xa7MHswGXAVy2Ogv/iER61Mp1AhwVdRnJbMGKE17YUicVxGms0OHrY1oLqQ PorQ8fTo97EiiWnBDnCWma33Yi0PyKB8nElkMDn0Wh374bDoxnhh+Ev1uUL5XKJPHSk9 aaJ1gt9XgUjAw52nBstN6loz7qOufZ/UQiTrqFOLKvrOWCa7ZVr5GvGzw/pPqoBHdziC MFzjrKx89NHZ8oFK5xKIZ0Dh/9IkbwWnyj8YBFLBRBhBs/rvUIwH9ZJ29rwO9og5Gc1X UM5g== X-Gm-Message-State: AO0yUKV7RRSsVbLhqVD0YtsY1mSYU/qFNh/yBOsTnnM92J91N4+nU5lH bX+aGCG291cTWQZ3Ikm/qGg= X-Google-Smtp-Source: AK7set9jL/YurVg1LrqMWj6gU+z5tA67pKXcqVUOF1awjSU3saKBO6H3ndM/q+6QU8miQSh5MvPbhA== X-Received: by 2002:a17:903:110f:b0:19a:67c0:53ee with SMTP id n15-20020a170903110f00b0019a67c053eemr1337211plh.54.1676440195905; Tue, 14 Feb 2023 21:49:55 -0800 (PST) Received: from localhost ([58.34.94.196]) by smtp.gmail.com with ESMTPSA id g21-20020a170902869500b00195f242d0a0sm11163780plo.194.2023.02.14.21.49.55 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 14 Feb 2023 21:49:55 -0800 (PST) Date: Wed, 15 Feb 2023 13:49:53 +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: <20230215053748.GA11780@Jiazi.Li> References: <20230214101949.7461-1-jiazi.li@transsion.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 187E9C0136 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: 9bfgm9kcjtuoy1zq3sx1x8i339wek9qf X-HE-Tag: 1676440196-703712 X-HE-Meta: U2FsdGVkX1+T/W4Mt1ahxc2B1XszP5i7RwtguugS29kIfXpKbND7AcamcSGRj/9KZBbiPrYC8tBguI03p5myYhpvV/2iapUeXOEC4pEDEBCNUrjwJt6gUp3Mweet2FBES2N5Y2VDk4lZdweSJ9JcJGDnOb7kercklCsYcW9BlDyz3C/f/0x8MWt9huqfVqvoOYQIPRUrFLzuegTy3o18MpoJ3wNHNDW58av9IcSvXUgEGpj6uONs4kNRpo5u6QEPuBcHy6i5bHhqlvumHw4CONf3E1BxBzHxmonYnnvvwHnz3hLAq4x+zx4VuENcTYq1CLGvbJqY6/bv2nbzER0orhRaq/ovy2eAkOB3JqBG4v3EGoVpYPxZx1byWp3H3PeBifyqLKg3twlqSh6m+6c7m855QoLzE6yqDiLE+TZq/wGYH+3TuBEjyWfNkedPhWjFl5ga0DOJDoUAYrIG/P0yXsP2GbtcfUX3Pz1/o0UkF2yj/9p/wLp37V1ORAZgFEwBWUxzLJHAymIbOy88KXjBAQzxkEhpAHo2DwQR8nGvLZftJxE3tcvRoayG6JeTdYP9H8kNULgymA4vAki4KWkBZxd2N/GSrYCFgR91TWiGSn/YLv73s231ael5zEOMTh8vbN10dkFk4tgbh9NBeJJb/R5iBJ0yefaN6tDplwg0+7SYSHZc5iwJ1WL7OxT+EeGXVcXBHtBmdDE+Pic9V6I5fykXp9JaPvvz92jtBWSWoeDs+Ib0NBhHc9vnAiBVW/yRdS9zBHeut5Q1twdukwcWa4ppiPADCvqcfdQKkxj8vn1yXUyEoIt60XmBQv0X7/F/StJIZyA4p1IdTonDS51TTaPDTaQBrwY8dREHCYtOMq+/vreE4Dko7S0lg+9WAoTPRHt+PPJQQ82rVjuKejw8qIdbtV6d0lq2i4OLMbP0T8noguYy/u4WnPCeN3KJnL55GGtmzB4FBMmkVOTxno/ hXjWsnkr qSUX4LJGML6zgDfQZgPdCEif/F6bKFtZUUJJSAVfrAOYJN+zUBj5Oob02qgp+De3SuMgIT3DJGb3suHrW6Wv+eoJ5+/30ao7kVx3HlDUs/MFeUyD/6J7CAOo/0/ZYFdMAhqjbP9Wj7/SNYxyC0gsjey9Jpnlo3n3WZoM0ZGVep+YkramenHvp/9/RTWpv+cr1N1Xtm86EaVLDQEnhYwMPmH3RCh4mCZZcaqVSq36+gMLKc6U7JTTLLHdURlDWVvC9VbjBT3n4c2qjOL9F67G92ddg//KElV2wA3TLbki89Kgi8YrRYmwrc/YuV8G4hAz9cpBIFATF91hU8uHBfyvPKOg1XZXvlv//FxDznp4gm+TfUmC3gPwEgkQbx2iv+fA3fEHCdJfodxv2nAVuvNPs61GX5VrINLHX2qzQcyOiVjS4UUAwYqD7YpfgtvBDbD/nIOA0qhHJ6wL7JniYLc0hCyqj2jzzHioYmuhli/l725JM38gCwodcTFg7/dxP1DvbMu5LjOGVz9PlJP2yEgGQuWDIas2N1yEKBvtHoQxKUThAyK7O9Mq6ENqQXJpR1gr+QCsdAwdakmfpU/Q= 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 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. 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", >