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 E5864C001DC for ; Thu, 27 Jul 2023 07:26:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5D4F96B0072; Thu, 27 Jul 2023 03:26:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 584D18D0002; Thu, 27 Jul 2023 03:26:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 44D166B0075; Thu, 27 Jul 2023 03:26:54 -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 3783E6B0072 for ; Thu, 27 Jul 2023 03:26:54 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id F0F171204D9 for ; Thu, 27 Jul 2023 07:26:53 +0000 (UTC) X-FDA: 81056559906.23.C184563 Received: from out-24.mta0.migadu.com (out-24.mta0.migadu.com [91.218.175.24]) by imf16.hostedemail.com (Postfix) with ESMTP id 011F518000C for ; Thu, 27 Jul 2023 07:26:51 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=KskOes02; spf=pass (imf16.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.24 as permitted sender) smtp.mailfrom=muchun.song@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690442812; a=rsa-sha256; cv=none; b=VaIlTycH/al5EJXROZNQ+yhP06DCdlwNypcEI0z+2b7dZmUIw10YMdzCLgSeeoLZ933hjO wQTvYF3fRVWXliRPV2KqZLJWb4ieFQlxH3GJ2QXi5+hPcmV6VORR+sADhLZkEP07acoUkY szl+Xps8bh3kaXaDYRF6kuUZA/+qBlQ= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=KskOes02; spf=pass (imf16.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.24 as permitted sender) smtp.mailfrom=muchun.song@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690442812; 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=y9XMebB6M2nB9lb6sk6Glc51gIIG/j3lJ90cd3ChxDY=; b=UeQHq9DjY7O24+A+bEl6BvtAzC7Ys7FfZGIZyNZdwhYqzKw+c9oo5NqQNydugOdWRAbvaZ S5t2Ht47Ky9NMUwAwb84CkIxi71oN0gYwzIKsShWSKrJx7cofXeRGN1RJsM+njGwPsNGCY SohUl/amx35I6tUxDyH3EU50MBlSBwE= Content-Type: text/plain; charset=utf-8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1690442810; h=from:from: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; bh=y9XMebB6M2nB9lb6sk6Glc51gIIG/j3lJ90cd3ChxDY=; b=KskOes02uBFfe8ajD1gfxr4/xNiq8bXk00RvKDTGHf6JaUPn67QcMMDEnYhj3T7jfR00+l u3jC+dS+3iV81GhfawLYXIsfXvr9kOtjVQl/fb2omFd3RXx9CrHXpbwWaXPTqLTB+H5Rnf AxKcbgSScmuFU6EGYlqv1reJBLqKRck= MIME-Version: 1.0 Subject: Re: [PATCH 6.4 000/292] 6.4.5-rc1 review X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: Date: Thu, 27 Jul 2023 15:26:12 +0800 Cc: Linus Torvalds , Marco Elver , Roman Gushchin , Andrew Morton , Linux-MM , Naresh Kamboju Content-Transfer-Encoding: quoted-printable Message-Id: References: <20230721160528.800311148@linuxfoundation.org> To: Alexander Potapenko X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 011F518000C X-Stat-Signature: rrcaenauaojbwdqob3io4mriu5kuh1ok X-Rspam-User: X-HE-Tag: 1690442811-747460 X-HE-Meta: U2FsdGVkX18HATaHkAoZ0ORhlzQyrTAtPv2pUSB4TF2TiVkG8vwGOPl7J1DovCQ8bAfWlRHSwSADkqoo+ovvm11LEwCTTX1F6/V4TyyK6EFAUZa4P/+GJCmMMBlu25mviC1ZL47Uajv2LeA6V2aJr5UooVg7VnONnKm3BPuh7mb0MbKi+yjAAeaWbpEzNsGCW02Aqhj0zUNilK3InBKvX5CeZvFuTN6GTh63eqshzJZmaO4cf3nnvvXrdPlpu4B89lF2Bto7YF9LUtmkHS2MGkjXSqKWH2MbIdKthVBPKYGt+iFmaOOIxUfhxn3Ji2WTCHbxy/99Y0fhCOeBq0HXEj9sPQKBDm+HLpeuqFRQg7cF6zMBEfjifZi4dMo8p+rOCWqTwCNaRjqFUcZibmkgG/OAIWMYFhcQbeKtkG+7KoFI6fmwqP7Uaiy0Nl2Xx+gMpouUsbXGgRpRP1c8Z3MDKLq16DcrD995ZTtNMq/1wTIqZ6cfXP5Qx2s+MOQ3vo6YVjmVONCHv2uRq+YgXTxeFXPRH16dr1P691Y2fF2LjttmcRNzTfnogs3xa9Er2LwkKfrosozdjLlhnVihOoRU8w1Foo4lN70x3rIvwrlXXV7xRlORDrXcVQkChecV7skTVqg89Y68CQTW6Uoe/6soyqpQ2uzcbaYmxwuk4xqAUXxul5ou/W4/XgIK84hJBB9vD0U/OguM95/J2U7dkqG7Ownc/wCORCoxNLAWDgCTzo3a2/ueWPHqOYW6W6X5FQCIuDnlWBXUX5LAgv0a4wIku6tkZ13rdgGbXMbL6p1JwZpqi3KdsveSwB//rZc24ZgBLgubs1K8nAog4gZcFez88RNe7wrxS/l1Kn+zmKns+c6nWbk3lCS7MmwTxE9RWTphxjH2Beqf+UIFUm4IOzoc9aDB/NzT2XM0g6f7/wUk72FDic/lvJhDs5l2M/jcWrDvZP+4JLdzQVAmWVuePRI nOu6r30j o+4gy1EPn8TzEhNZJ9pwTsKb+kTsaclgMN9dk1arO2N6s9XfRLJaCnUk+zNfxPzErk/1GS8Rx/TuYmr1DOHbXNyE4ozWAejYdrEV2WKROXGW1h7aOrAdtsqLaIM2rsH0GPPGfWxj0a5WEmmMoDAHoDugPrJJLZ8w8wRKY0oOnklelAlaUyndJC0cPUoRt2nCRXjSRlsS4zJfjtzefJ/P1Dbt3nC6ASZKDvKNeSoMDFmSVLhuqm0z0siBXKpG7f0+BSIDYrlxWJ9prh0VndZXNaEDP3KMRH1dooNg/qtqDLOktgo8c/gBB+XpQ9eUWXhivTETV0X/HRDd4DGgH4qYxbyGEsnp1uE/kf+SAPHVrRwmXeBQitHJf5ilfxg== 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 Jul 27, 2023, at 15:02, Muchun Song wrote: >=20 >=20 >=20 >> On Jul 27, 2023, at 00:52, Alexander Potapenko = wrote: >>=20 >> On Tue, Jul 25, 2023 at 6:21=E2=80=AFPM Alexander Potapenko = wrote: >>>=20 >>> On Tue, Jul 25, 2023 at 3:39=E2=80=AFPM Naresh Kamboju >>> wrote: >>>>=20 >>>> On Tue, 25 Jul 2023 at 17:22, Alexander Potapenko = wrote: >>>>>=20 >>>>> On Tue, Jul 25, 2023 at 11:59=E2=80=AFAM Alexander Potapenko = wrote: >>>>>>=20 >>>>>> On Mon, Jul 24, 2023 at 2:10=E2=80=AFPM Naresh Kamboju >>>>>> wrote: >>>>>>>=20 >>>>>>> On Mon, 24 Jul 2023 at 15:50, Alexander Potapenko = wrote: >>>>>>>>=20 >>>>>>>> On Sat, Jul 22, 2023 at 6:37=E2=80=AFPM Linus Torvalds >>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> [ Removed the stable reviewers, bringing in the kfence people = ] >>>>>>>>>=20 >>>>>>>>> See >>>>>>>>>=20 >>>>>>>>> = https://lore.kernel.org/lkml/CA+G9fYvgy22wiY=3Dc3wLOrCM6o33636abhtEynXhJkq= xJh4ca0A@mail.gmail.com/ >>>>>>>>>=20 >>>>>>>>> for the original report. The warning was introduced in = 8f0b36497303 >>>>>>>>> ("mm: kfence: fix objcgs vector allocation"), and Google = doesn't find >>>>>>>>> any other cases of this. >>>>>>>>>=20 >>>>>>>>> Anybody? >>>>>>>>>=20 >>>>>>>>> Linus >>>>>>>>>=20 >>>>>>>>=20 >>>=20 >>> Muchun, any chance you know under what circumstances a KFENCE object >>> has its meta->objcg set to a non-NULL value? >>> It seems to be a quite rare case, and I've only seen it in live >>> radix_tree_node objects. >>> Since the check here: >>> = https://elixir.bootlin.com/linux/latest/source/mm/kfence/core.c#L1097 >>> ensures that this value is NULL when the object is freed, where is = the >>> code that is supposed to zero it? >>> Could there be a race somewhere? >>=20 >>=20 >> I am still puzzled about what is going on. >>=20 >> As far as I can see, when KFENCE pool is initialized, for ith object >> page in the pool its page_slab()->memcg_data is set to a value = derived >> from kfence_metadata[i].objcg >> Because KFENCE objects always occupy one page, no two objects are >> expected to share memcg_data at any time. >>=20 >> When slab_alloc_node() is called, it first invokes >> slab_pre_alloc_hook(), figures out the obj_cgroup and charges it for >> the allocated memory. The obj_cgroup is returned to slab_alloc_node() >> and after KFENCE allocation succeeds is passed to >> slab_post_alloc_hook(), which then writes obj_cgroup to >> *(page_slab(object)->memcg_data). >>=20 >> When an object is deallocated, slab_free() calls >> memcg_slab_free_hook(), which zeroes *(page_slab(object)->memcg_data) >> and passes the object to kfence_free(). >> At this point the object's meta->objcg must be NULL, so the warning >> should not be firing. >=20 > At least, totally agree. This call stack comes from slab_free() which > makes sure memcg_slab_free_hook() is called before kfence_free(), so > meta->objcg must be NULL. Otherwise, seems something is corrupted. So > I really want to know what's the value of "meta->objcg" when the = warning > is firing (e.g. whether it is a valid pointer or does the last bit is > set with MEMCG_DATA_OBJCGS). Maybe we could improve the warning = message, Sorry for the confusing, meta->objcg should be a objcg pointer, it cannot be set with MEMCG_DATA_OBJCGS. > e.g. print the current value of "meta->objcg". >=20 > Thanks.