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 260C4ECAAD3 for ; Sun, 4 Sep 2022 10:58:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A34918018A; Sun, 4 Sep 2022 06:58:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9E5058D0031; Sun, 4 Sep 2022 06:58:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8852F8018A; Sun, 4 Sep 2022 06:58:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 7A2758D0031 for ; Sun, 4 Sep 2022 06:58:57 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 51B6AAB2D4 for ; Sun, 4 Sep 2022 10:58:57 +0000 (UTC) X-FDA: 79874105514.28.E7987D8 Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) by imf18.hostedemail.com (Postfix) with ESMTP id 081791C005A for ; Sun, 4 Sep 2022 10:58:56 +0000 (UTC) Received: by mail-pl1-f170.google.com with SMTP id c2so6017684plo.3 for ; Sun, 04 Sep 2022 03:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=Y1gR7e1PQuUOnfe4Q+PhjAwNNQGKAewl720r1GJyD2s=; b=VV7shxrBU77p+TcGyUZBmHkujuebHJbChMeEuyKmGFS9napMdsAmE8z9PqVwNaeFn7 Z+g2ZI2bIDwX25TK1zG0KvNZd6u1Y52n8iNTHX4ngRozxSyUx0Wlh7fTkiU1MX8UNivI n58rwj1tlMQ+l7NJZp37TFyHbYA9DDa8MEaFW+8qT6lSNL8R+pw0FYcvWMb4ir/327pc UM5PappO32ZVumnu9NGZDn1P2rFmJoEYObwfGvrQwxDPeZqiaueh0P9PXIWXFGbz9JQC LAJnA0jQNczL4CQHdMem5IovYJM5Xyc+sBy5X40gvxZAyKNFGIHvqcKT0av+sRu7R0fa 5EIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=Y1gR7e1PQuUOnfe4Q+PhjAwNNQGKAewl720r1GJyD2s=; b=0+xbwAvPgxUw7Wuy+xeUs2Rlb9cD/kpetXudaL4/nse62ZGcSidqwssYb+e1PB17o0 VWGlJNgu1UzMqvpJEPrHcTaHGxrKV+UpR63DpG8+LZ6oQWldDx6xB/c4fSk/8nSWbMJY duNynP9SYihAXhv++Q2LsbcUvO0zphgg8fWqu4fItqPi1TYD2J9hy9SMin1jR/SDjBzC xMAnmvJlNnEX+p0ZcUAdK2zd4gNmvAHozXKBKGzvYpu74eAHda+S5XQtZxqhP9WtnWa7 qgDRLuNkW1xZZEGOpHOPmac2q3f9ixBRL09o8NHARG2phHwHCOehp1+X7eUmDM6zztz4 fodg== X-Gm-Message-State: ACgBeo1a4G8qA3/Y+biWOpV8+yUSp7N+JeytE2+JF57dOgpSKtUkAvqy 552QlCNubAoeKc+lEQIIoVc= X-Google-Smtp-Source: AA6agR43WivJ5n9DybEFsqFAJyKm77SN9zl396bmwfcC1aJPgmJH9nzc64wRma1HfcVBC3Q1bKxR+A== X-Received: by 2002:a17:903:2441:b0:174:7f19:41e3 with SMTP id l1-20020a170903244100b001747f1941e3mr37309073pls.79.1662289135877; Sun, 04 Sep 2022 03:58:55 -0700 (PDT) Received: from hyeyoo ([114.29.91.56]) by smtp.gmail.com with ESMTPSA id q23-20020a170902bd9700b0016dbaf3ff2esm5169078pls.22.2022.09.04.03.58.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 04 Sep 2022 03:58:54 -0700 (PDT) Date: Sun, 4 Sep 2022 19:58:49 +0900 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: Feng Tang Cc: Andrew Morton , Vlastimil Babka , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Roman Gushchin , Dmitry Vyukov , "Hansen, Dave" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Robin Murphy , John Garry , Kefeng Wang Subject: Re: [PATCH v4 1/4] mm/slub: enable debugging memory wasting of kmalloc Message-ID: References: <20220829075618.69069-1-feng.tang@intel.com> <20220829075618.69069-2-feng.tang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=VV7shxrB; spf=pass (imf18.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.214.170 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662289137; a=rsa-sha256; cv=none; b=Vwd5f01afBna3hszVVSUcFhW8JKzhMGD6LOrDzozJBVQSwMshPQhY4jJ1F5aBEf5f+UEaS Th1VaA0B220O6Mz35q6lFanCUsk7xcYp6653Llvi8E0GgFlEAF+6TE/tsCYWTlzR8YZM9B slKcZR+qpgNuy+4ssq4f4cWmWXfkXTM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662289137; 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=Y1gR7e1PQuUOnfe4Q+PhjAwNNQGKAewl720r1GJyD2s=; b=OiGpybQWHg4MZCn2frzmycrkid0YOjvxV31kKeCr7gBuShlUCaRU72d2eoaPAr60HgBiWn 9xTQH45rXO0imGld2uCeBURtVWzayKdx0E+GUdQNP9F3JtHqkYAGce1r1C0D/dfGJwJm3r j2s1V3Z+6mw74oIuqFVrIuI1xZxwKos= X-Rspamd-Queue-Id: 081791C005A Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=VV7shxrB; spf=pass (imf18.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.214.170 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: pdhesb15zjt8e7kith8x9e81zusn1shk X-HE-Tag: 1662289136-166538 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 04, 2022 at 05:42:33PM +0800, Feng Tang wrote: > On Sun, Sep 04, 2022 at 05:03:34PM +0800, Hyeonggon Yoo wrote: > [...] > > > > > > > > This patch is okay but with patch 4, init_object() initializes redzone/poison area > > > > using s->object_size, and init_kmalloc_object() fixes redzone/poison area using orig_size. > > > > Why not do it in init_object() in the first time? > > > > > > > > Also, updating redzone/poison area after alloc_single_from_new_slab() > > > > (outside list_lock, after adding slab to list) will introduce races with validation. > > > > > > > > So I think doing set_orig_size()/init_kmalloc_object() in alloc_debug_processing() would make more sense. > > > > > > Yes, this makes sense, and in v3, kmalloc redzone/poison setup was > > > done in alloc_debug_processing() (through init_object()). When > > > rebasing to v4, I met the classical problem: how to pass 'orig_size' > > > parameter :) > > > > > > In latest 'for-next' branch, one call path for alloc_debug_processing() > > > is > > > ___slab_alloc > > > get_partial > > > get_any_partial > > > get_partial_node > > > alloc_debug_processing > > > > > > Adding 'orig_size' paramter to all these function looks horrible, and > > > I couldn't figure out a good way and chosed to put those ops after > > > 'set_track()' > > > > IMO adding a parameter to them isn't too horrible... > > I don't see better solution than adding a parameter with current implementation. > > (Yeah, the code is quite complicated...) > > > > It won't affect performance to meaningful degree as most of > > allocations will be served from cpu slab or percpu partial list. > > Thanks for the suggestion! I'm fine with it and just afraid other > developers may dislike the extra parameter. > > The race condition you mentioned is a valid concern, and I have thought > about it, one way is moving the set_orig_size() after the redzone/poision > setup, and in 'check_object()' we can detect whether the 'orig_size' is > set, and skip that check if it's not set yet. As the manual validate_slab > triggered from sysfs interface is a rare debug activity, I think skipping > one object shouldn't hurt much. That will require smp_wmb()/smp_rmb() pair to make sure that effects of set_orig_size() to be visible after redzone/poison setup. Isn't it simpler to add a parameter? > > Thanks, > Feng > > > -- > > Thanks, > > Hyeonggon > > -- Thanks, Hyeonggon