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 2CAFEECAAA1 for ; Sun, 11 Sep 2022 11:52:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BA0E18000F; Sun, 11 Sep 2022 07:52:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B4EC180008; Sun, 11 Sep 2022 07:52:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A3DBE8000F; Sun, 11 Sep 2022 07:52:06 -0400 (EDT) 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 95CFE80008 for ; Sun, 11 Sep 2022 07:52:06 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 6C91D4049D for ; Sun, 11 Sep 2022 11:52:06 +0000 (UTC) X-FDA: 79899641052.30.E777AB7 Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by imf25.hostedemail.com (Postfix) with ESMTP id 1BCC1A00B8 for ; Sun, 11 Sep 2022 11:52:05 +0000 (UTC) Received: by mail-qt1-f176.google.com with SMTP id h22so4432318qtu.2 for ; Sun, 11 Sep 2022 04:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=MQaM98zF6Au3ifgBX1LN9vhnn6oLk/4qb19oOxSo2ys=; b=SigBH0gvrEn1MEJM6v83gDZiBN7mUjGGRt4qVaAat9iISUXJD8JcDqtiVF/84C6yXf AKj/3foELjE98IRegp7cjL3MAqtx9H0Yp/UluKzROBF4yJ17gVd9gRzks01IxNrIlEV9 H+F4IesaKttoAQlIBWKSCYzoAZp3sZdfA3HK8fviZeLfwD8A015T4mSrc8ANPBGla0BO yIO1GuLrrUIyDbSRWU7nHd5IXarxGehiiYze0OKQYJUbq52Z+DSDMGOkpKmu8ueSY+QL GoxOcp01Kdj+CvQdu+8ojPRDAyD8Rj8XwxawNeV/S+h+Blac5xlAOKlnG/5aYILTED2I y5pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=MQaM98zF6Au3ifgBX1LN9vhnn6oLk/4qb19oOxSo2ys=; b=LDcT6BP6a5pX2s/o4MM8k5hxoYMPGGCAnv3VJHBV9QaIkbmc8w6UvOI83rQaS2AobH JV4UP2/uAqlwaZkpP441ZNA7tAF2iAV607wjAaTnFguU57fOmprB75F9dcv6Ps0b6blx 2cXvYobwWcq6/nWT9RuFPimMw0+bNwoFxcG8Smm3UMqNwnKry1gg8uv5fnvIMvuc4lXx GPA8dHSxFxbXfQXAy1Xy3BQBmQ7FdkTlIM68nx4CJfEU02lIh8I5ccMfdLqBjFoqP4JB EfCKXb7QNhJn5Nu3yvO1EhmSLmw+EJNC0BS8XlbwjwtyDdjgNzfAkOkHJwVuTjhpM9ZN NXaw== X-Gm-Message-State: ACgBeo2oWgLbAEjAndFnNhzva3JRfpiD7HcT4ccTy9rpkC2X2ixKOynK 7Tq8zIDcGf2rG3RdzWIYc2kmTBPqyrf03Ij8EdU81v9DJpo= X-Google-Smtp-Source: AA6agR59yOWQiuef4RAzd0Ue1tcPYotyEFBsUgd+CB1gxXMS9L+XZKteCqvdhwqa8jqp9+HXQehG4aJQLaCeAtS93eI= X-Received: by 2002:a05:622a:14d1:b0:344:b14a:b22a with SMTP id u17-20020a05622a14d100b00344b14ab22amr18977092qtx.203.1662897125285; Sun, 11 Sep 2022 04:52:05 -0700 (PDT) MIME-Version: 1.0 References: <20220907071023.3838692-1-feng.tang@intel.com> <20220907071023.3838692-4-feng.tang@intel.com> In-Reply-To: From: Andrey Konovalov Date: Sun, 11 Sep 2022 13:51:54 +0200 Message-ID: Subject: Re: [PATCH v5 3/4] mm: kasan: Add free_meta size info in struct kasan_cache To: Feng Tang Cc: Andrew Morton , Vlastimil Babka , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Dmitry Vyukov , Jonathan Corbet , "Hansen, Dave" , Linux Memory Management List , LKML , kasan-dev , "Sang, Oliver" Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662897126; a=rsa-sha256; cv=none; b=MfmZQZmOuoJleXXJ9DVqjU4528RiyrndMVcyerJw1q1nAQ0rxVNxccW4DbrzDZfUE9OADf cF6fN8CRy+iG+vr1gmmwNfaNFZIsI4EDg5P5fV92iq3WXE1EQAHJYNReQstvQHsWtm0lQ4 XmDGK12cP/IGILqzy/PJvGEtdcS3l1g= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=SigBH0gv; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf25.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.160.176 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=1662897126; 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=MQaM98zF6Au3ifgBX1LN9vhnn6oLk/4qb19oOxSo2ys=; b=2aF6VoO6RuI9KyyiUQuBgZ7vzrHdIcYBGZ8G81PQ58NbUha/MesBXABeDB3BpUG1QN3xxN UTmGp3tFDe1g++JNZj2e0q7D8W0aZZaPzPDuuquO1SAU6GdrCy0Zp26hCTzVe0oQY9Qg1p Wd97W2lsTKlTSbt1nQ4bpUfG/2TDqm4= Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=SigBH0gv; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf25.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.160.176 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com X-Rspam-User: X-Rspamd-Server: rspam10 X-Stat-Signature: xfox5u5nfepe849188765zwskwmfss3h X-Rspamd-Queue-Id: 1BCC1A00B8 X-HE-Tag: 1662897125-922249 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 Sun, Sep 11, 2022 at 5:57 AM Feng Tang wrote: > > Hi Andrey, > > Thanks for reviewing this series! > > On Sun, Sep 11, 2022 at 07:14:55AM +0800, Andrey Konovalov wrote: > > On Wed, Sep 7, 2022 at 9:11 AM Feng Tang wrote: > > > > > > When kasan is enabled for slab/slub, it may save kasan' free_meta > > > data in the former part of slab object data area in slab object > > > free path, which works fine. > > > > > > There is ongoing effort to extend slub's debug function which will > > > redzone the latter part of kmalloc object area, and when both of > > > the debug are enabled, there is possible conflict, especially when > > > the kmalloc object has small size, as caught by 0Day bot [1] > > > > > > For better information for slab/slub, add free_meta's data size > > > into 'struct kasan_cache', so that its users can take right action > > > to avoid data conflict. > > > > > > [1]. https://lore.kernel.org/lkml/YuYm3dWwpZwH58Hu@xsang-OptiPlex-9020/ > > > Reported-by: kernel test robot > > > Signed-off-by: Feng Tang > > > Acked-by: Dmitry Vyukov > > > --- > > > include/linux/kasan.h | 2 ++ > > > mm/kasan/common.c | 2 ++ > > > 2 files changed, 4 insertions(+) > > > > > > diff --git a/include/linux/kasan.h b/include/linux/kasan.h > > > index b092277bf48d..293bdaa0ba09 100644 > > > --- a/include/linux/kasan.h > > > +++ b/include/linux/kasan.h > > > @@ -100,6 +100,8 @@ static inline bool kasan_has_integrated_init(void) > > > struct kasan_cache { > > > int alloc_meta_offset; > > > int free_meta_offset; > > > + /* size of free_meta data saved in object's data area */ > > > + int free_meta_size_in_object; > > > > I thinks calling this field free_meta_size is clear enough. Thanks! > > Yes, the name does look long. The "in_object" was added to make it > also a flag for whether the free meta is saved inside object's data > area. > > For 'free_meta_size', the code logic in slub should be: > > if (info->free_meta_offset == 0 && > info->free_meta_size >= ...) I'd say you can keep the current logic and just rename the field to make it shorter. But up to you, I'm fine with either approach. Thanks!