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 5FC1FEB64DD for ; Thu, 27 Jul 2023 07:03:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DDF836B0074; Thu, 27 Jul 2023 03:03:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D92C68D0001; Thu, 27 Jul 2023 03:03:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C30306B0078; Thu, 27 Jul 2023 03:03:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id B62AC6B0074 for ; Thu, 27 Jul 2023 03:03:30 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 70453121037 for ; Thu, 27 Jul 2023 07:03:30 +0000 (UTC) X-FDA: 81056500980.30.355D387 Received: from out-43.mta0.migadu.com (out-43.mta0.migadu.com [91.218.175.43]) by imf27.hostedemail.com (Postfix) with ESMTP id 923BD40012 for ; Thu, 27 Jul 2023 07:03:27 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=obt61cX7; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf27.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.43 as permitted sender) smtp.mailfrom=muchun.song@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690441407; 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=HQP09NImTtuRppiFLJ8qxZM3dq7EdD/2Jw39SuTeE1k=; b=rYhDKbOSaPydYdAVqtqj2sGzQHVnJOtFk6pNkSWaVGMN6RWBlOVs9YDfqyPPQ7Vlz02NQn 6+kjQthtX8xsO8UVlQUsUKe6BfwWLqrIkSxtu59kuEFifpdnuJYdmGFE3+rX7gUi36LZ1o hxiQwW9QtoezLapAFm1Nb59AZDMttjs= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=obt61cX7; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf27.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.43 as permitted sender) smtp.mailfrom=muchun.song@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690441407; a=rsa-sha256; cv=none; b=BxL2gaL5SfhaWZxt7A+mWqSbYj1PByIcatIPFkC8eBhNFt/SqHDg1r84jBYrbIPFkpwXiB Q2QFoMYZkhn7sgq59MlV3X3sXfyzNZSKmIlILsdWnodVZrpZDI3XEbBi12aKSV3eV5CURU tWFwEZjTV9Fr1HmxICaUwv9UPW7gIPo= Content-Type: text/plain; charset=utf-8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1690441405; 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=HQP09NImTtuRppiFLJ8qxZM3dq7EdD/2Jw39SuTeE1k=; b=obt61cX7y1YwGA54nef6jvDWjPbOasYFiVEsO7ogE1wW0k0kMCEbvVWiOSmYZ3Q+ELdCYY ciKLlazgFFoEQ0qcfYiREzQq5+xJC/d3SwrxHxCsBrmWxs+j8WQywF0xLX0YIK55Dz4aot z7eJL7fXaVKWsHSERIvkCXjCj4IMXz4= 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:02:40 +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-Queue-Id: 923BD40012 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: i3oke4w9p6ahuzp7tyjtuq58hy4z8t7j X-HE-Tag: 1690441407-479315 X-HE-Meta: U2FsdGVkX19CpntOXrIBNN5+AMjHumhjSp1OBVJcUJr7loFKCngMhPSQVU8iaPvAreQPZQWuZ0nG8Q8QI4G3HQzMY+fo2v/TyD8PemCVtbaC8pYTR6HIjSZPbjxFZk7Qe/geWr3yhTXTYWDIpiAtmg8H4ee6j6UvZh77ZMLvj23ssZwq0sBK62tEeVlzJSojwH1V4KOVdBWoiahDpih1gPHKn8n3PYGpRbzatyaqQlVj9jG8NUszsz5Gw35r2xrio/Bx3FnsxPWG4vog5L/9NJvn2iJx49qHp36vvvqlSdai7xlwngdFSic1nVjqVOJj/VHEBiG5ecFix4izgvwTnbeC4SHDC4KKPlKXeoBPtQ4P22p6pgT8xVwACyKyoeezgpqp0KmqtkyYjRrOFdeLNxSYTUxV3gIrc2UkGXzq8ZfqYhTbKmO970AisECrwnOqockrQx5gvNYvR0+OSCzhOIY1BhWaR9+uSCsoZdBdnUk95Ibh7ilBU7w5ZkX9sjLc5tOAbohJb/44PGRIdOhmntoPYUH5Wap2UfCTZJciFq0NNSu5qJSZURLrFdmFE73p15vxZ/ym599EAaGJuWHUoa1iPzwIpJQZ0hPdDyXOk429DhSv3raYkAM3VLIhizmMuu1FvMoqDafjvBKIU5xFztsjk1LGVz4WxGum43dXwDaNHJluE7QNSyjL3NlHtb+rwg7/0Kx5pWk0kd2ooaqjNCMlvYi9E/4E4OUlqE8CdGtTGbdo2VU0VxgVG+fhen28u4E/+iEine8IYkdDF5D+9VDp1ppfdcCHMtyO5lxbzbK3MDYyskqYTumcA32mj2oBHoyWDz4hq93s2uB1CAWGtDz85y0Fc258y84cPfpoHobjpByg1C+j1Qj2XAlwQPqFfhFvO6CxSlzPHoYZ9ynnOnbDsFB/uTeGIImcDE0v5XlOTawjf1LoUVkObOEhd5WxittZg9Kt3kFm3zh3rKF TtBArxfc R94RpRKkADhw67nuQKRPGKGD1JGJw1fK6X5qX/L3OWY+0p4OczkuAmklwN6wfj8izZNxC+3c48nsrYFTUJgyEkutNkqkUVoXn8xOyQh9DDd/RviiIJnMYAF/3jWqvC7hvp3cVKt6z/804TDTAynpsI1UQE7Jdb9A0pjJxtuq027sqfI8ptnTNxfQMoVGStebUU59+ZgMCYUGUTiO18uyTWy+1+W1HW+a0FpQWV23QucihVsOCXkIsWKkZrRGeoWAz5qZrs+IJSV6VXSJkpcKdIbGYl6JyVzN//EL+8lrXRewF2Ljcj/wBLJvCL6Id1Zyf0WO/dgV2SNfBIIz/0mzziKuRroMjVL90DxAFo50XgvhBE0mLVumKTUfxZw== 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 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. 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, e.g. print the current value of "meta->objcg". Thanks.