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 4E08CC369AB for ; Mon, 21 Apr 2025 07:46:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 948FA6B0006; Mon, 21 Apr 2025 03:46:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8F6B06B0007; Mon, 21 Apr 2025 03:46:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 770046B000C; Mon, 21 Apr 2025 03:46:04 -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 4FCB86B0006 for ; Mon, 21 Apr 2025 03:46:04 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 00335C19CA for ; Mon, 21 Apr 2025 07:46:05 +0000 (UTC) X-FDA: 83357267490.03.81C9FDC Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by imf11.hostedemail.com (Postfix) with ESMTP id AFAC940005 for ; Mon, 21 Apr 2025 07:46:03 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b=fZpU7HWY; dmarc=pass (policy=none) header.from=quicinc.com; spf=pass (imf11.hostedemail.com: domain of quic_zhenhuah@quicinc.com designates 205.220.168.131 as permitted sender) smtp.mailfrom=quic_zhenhuah@quicinc.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745221563; a=rsa-sha256; cv=none; b=KUhv+e7Hw0dDg8JI+MiFeVhaa8vZs4RR9Cz/ElAcpqQbV5Io+t96PGrh2sQnK06CWfcqNO 6xmewqVy4Q5Ve/q1/yfoTdUrhvn/6TN+n49YTJAN4aGP7NfR88iYjEhkz2szkWO0zUKhBp Jm3Y+LKYL3fY/eCqFgCbFSJaGzkLqeo= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b=fZpU7HWY; dmarc=pass (policy=none) header.from=quicinc.com; spf=pass (imf11.hostedemail.com: domain of quic_zhenhuah@quicinc.com designates 205.220.168.131 as permitted sender) smtp.mailfrom=quic_zhenhuah@quicinc.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745221563; 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=u/2VdwI72slCSKnJQaTEkuv8ka/G3kd/+oTh01RpLAU=; b=pDsyk7yrCWMaSMDYHlPk5JhE8DJdwcG9OLCIN4WND7OonaGp0Z3P1kbtHsDZ4kmr6IyGdx wMlwf4X/z8u9mEfxTazOvqZZs0iPJNQfeVQdNivElzbEmP+RhTAKW6KULI8C5Alq/XcojG /vCJD9HUovYOi6lRy3+sRwgHMYsZLY8= Received: from pps.filterd (m0279866.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 53KMK2PS004392; Mon, 21 Apr 2025 07:46:01 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= u/2VdwI72slCSKnJQaTEkuv8ka/G3kd/+oTh01RpLAU=; b=fZpU7HWY7kuNZoKv 5H9EhiibhwtGyGiJuP23H8YYASIH2/vBM0MXp4zLLOceMY+AKvDyj+NhOrwxAfqx aq4W8IYo1djNzJNxeN+WAdh399eXMXcXSv5+ueCkl6+Z6vyov0rupgzcJzbkiHvc JY6hUMC8jwbi6blSibou20/HfpU9nO+qu7FRcPN7MLmz9orihFrIeV1rtqu+UbKq zOfEC6NJdDKX2AggwZZRYHvP4Um+CQIG4JIt9vPg8FGgd4VBS1kUiICwFNWZU9PZ kI7+EyGsFAuMecnVxZwrEbc2T0/WHYCBUtqWTeWjsGscdnp9p82UrCsAdSd3aiTs 7cdiGw== Received: from nalasppmta05.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 46454bkanb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 21 Apr 2025 07:46:01 +0000 (GMT) Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196]) by NALASPPMTA05.qualcomm.com (8.18.1.2/8.18.1.2) with ESMTPS id 53L7k09S006425 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 21 Apr 2025 07:46:00 GMT Received: from [10.239.132.245] (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.9; Mon, 21 Apr 2025 00:45:57 -0700 Message-ID: <89b3fbd5-d817-4f43-9721-6a64e5153be6@quicinc.com> Date: Mon, 21 Apr 2025 15:45:54 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm, slab: clean up slab->obj_exts always To: Suren Baghdasaryan , Harry Yoo CC: , , , , , , , , References: <20250418061459.3898802-1-quic_zhenhuah@quicinc.com> Content-Language: en-US From: Zhenhua Huang In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) To nalasex01a.na.qualcomm.com (10.47.209.196) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Authority-Analysis: v=2.4 cv=cdrSrmDM c=1 sm=1 tr=0 ts=6805f7b9 cx=c_pps a=ouPCqIW2jiPt+lZRy3xVPw==:117 a=ouPCqIW2jiPt+lZRy3xVPw==:17 a=GEpy-HfZoHoA:10 a=IkcTkHD0fZMA:10 a=XR8D0OoHHMoA:10 a=yPCof4ZbAAAA:8 a=COk6AnOGAAAA:8 a=u5Vm5Qlev4DUF23fx0IA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=TjNXssC_j7lpFel5tvFf:22 X-Proofpoint-ORIG-GUID: 44RLd3tKO7_fLQeP00ttHKhGs_DDtAoV X-Proofpoint-GUID: 44RLd3tKO7_fLQeP00ttHKhGs_DDtAoV X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1095,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2025-04-21_03,2025-04-21_01,2024-11-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 suspectscore=0 phishscore=0 adultscore=0 mlxlogscore=999 malwarescore=0 clxscore=1015 spamscore=0 priorityscore=1501 lowpriorityscore=0 impostorscore=0 bulkscore=0 classifier=spam authscore=0 authtc=n/a authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2502280000 definitions=main-2504210060 X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: AFAC940005 X-Stat-Signature: oc7y648ftym6swhdtt4455byeru1inth X-Rspam-User: X-HE-Tag: 1745221563-822880 X-HE-Meta: U2FsdGVkX1+qtG7a4pMxzXs23oOoFqhzn15eTDkzcCF3ZXeLNEndxbOkdPDWAGpFKlEojVW9CKLvMJBxv3ryKZNug4j1ovdg8X5MVPDB5pDBb50NnRA2y653EbXygQv65nzIzXw6h+pSIgds/iJ30Dnsu8lkX6yBrznfbh8eS/kJl+Gt0JXolZi2ZajTXLoE9/AJSjh1HG7fPv/R7ZqyGnE5L1yvXwh7tXvHeVtmk5Izt3jhnsO8Gypnu5MDsxFsPteXflJnmZNb7hvcFm3DJ+JLqO+bsMCsKBtazxLvE4KuRp80OjSbFg+wHl6jQlOu5fN7aTWLO9pMZ6bDkUDBy64WKMtWhacZ+khd2F5cSaN2r5mSe59GYkLv2xToC3FikMcMDNzvT1L2q4L78R9chakcB66F5gajiS1EZXR99lKk0bvnCj5vxBOdX9aEHItV3i+4a9ladcrLLJo6qyfvKokIR9uqgK67jOgT49D8VhMQ4pi/F9z2FoiiRxjAmm1ue0ENrwRPxJl60oR/W1oc/ZvUyL6Q5FFIkUtDFAfoEHdYlnO1ZD/NnIdi7QiIhobSDC7BVJS/MqGM3d/Utv+2886FUfITd4BWAz+ZrW1p6B1Qce45FIo+me5e12QYxH6dIDkU33h08KGTjAcnxcoU/geRfIQ0RWxYR9XV08cdyvQfmnozLKNnDQ6ydqGkw4spBXewx6C5x3Qpi3gbIDXYPeBmp74ONQSI4sE2LuJDtx1noYPD8o6boteQgYgy7csh17zQGkkVxkhzIRBAK1rCebz0fOyhh5ZM/iNRbriqmjwQ7pyJPP0BAtEVpj1ax+tloXCdLn/9rqZkX6eIjqqk6rL2P3BpOOBTOjj9/z5kpTTAVInMn4dNX31OcK28ZZRsA/SxiymRUAzQhQaI5f+InLB/EVmYXh4K7JfrPPHtTOkyGvwotb7KHarMG/m0kkNWTSJLFAVfeBXNQBHaRNB Xbc68gjS izA4M40vdreUnQTWsYpQSf2D0/hdPdNIDuBKAE5AtS3ZKv3GT6WrtXHlKjhncEGpZrYJaPweIgcyxElXYJuByxJ9fFyUFvuax0Nnkgv8njaKCwEbWpinf1vkPkuxlydG7g6jvcDaR6O0aI6oiiNESbJLdMT60axQiLSbWgXRwmR+3Yqx3xcAS9CxO9tIkbBAyBqdA8ARNRhZ0/NrB2LtS4ikmS2Pu9m7WIfSw73Lj1JXajg5RA4dFCi+/VW23UamoJhc4RzMx/s16PET1C9OsRQbVUQuzFwUV+IEUPobHuAMkOoloYi41tnuiUfk1I8019kLhJ9iA6n4nitmrMIzkcb0Whj4vXOMJVybbDIPdSMh6ri/hgyJi7+L+omFzUyYv6FUACuqpcd3CqMrX5pEPNPnmrQ65Fq0PeZSlgTgPQHdw5YhAigYqmnfxePqzidRaPVMPOJIMxaHpH8GVzr/wsqeMuA== 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: List-Subscribe: List-Unsubscribe: Thanks Suren. On 2025/4/19 7:09, Suren Baghdasaryan wrote: > On Fri, Apr 18, 2025 at 8:17 AM Harry Yoo wrote: >> >> On Fri, Apr 18, 2025 at 02:14:59PM +0800, Zhenhua Huang wrote: >>> When memory allocation profiling is disabled at runtime or due to an >>> error, shutdown_mem_profiling() is called: slab->obj_exts which >>> previously allocated remains. >>> It won't be cleared by unaccount_slab() because of >>> mem_alloc_profiling_enabled() not true. It's incorrect, slab->obj_exts >>> should always be cleaned up in unaccount_slab() to avoid following error: >>> >>> [...]BUG: Bad page state in process... >>> .. >>> [...]page dumped because: page still charged to cgroup >>> >>> Fixes: 21c690a349baa ("mm: introduce slabobj_ext to support slab object extensions") >>> Signed-off-by: Zhenhua Huang > > Thanks for reporting and fixing the issue! > >>> --- >> >> Acked-by: Harry Yoo >> >> I reproduced the issue locally and confirmed that this patch fixes >> the issue. >> >> Tested-by: Harry Yoo >> >> By the way, I think this should probably be backported to -stable? >> >> -- >> Cheers, >> Harry / Hyeonggon >> >>> mm/slub.c | 8 ++++++-- >>> 1 file changed, 6 insertions(+), 2 deletions(-) >>> >>> diff --git a/mm/slub.c b/mm/slub.c >>> index dac149df1be1..b42ce3a88806 100644 >>> --- a/mm/slub.c >>> +++ b/mm/slub.c >>> @@ -2023,7 +2023,7 @@ int alloc_slab_obj_exts(struct slab *slab, struct kmem_cache *s, >>> return 0; >>> } >>> >>> -/* Should be called only if mem_alloc_profiling_enabled() */ >>> +/* Should be called if slab_obj_exts(slab) */ >>> static noinline void free_slab_obj_exts(struct slab *slab) >>> { >>> struct slabobj_ext *obj_exts; >>> @@ -2592,7 +2592,11 @@ static __always_inline void account_slab(struct slab *slab, int order, >>> static __always_inline void unaccount_slab(struct slab *slab, int order, >>> struct kmem_cache *s) >>> { >>> - if (memcg_kmem_online() || need_slab_obj_ext()) >>> + /* >>> + * The slab object extensions should now be freed regardless of >>> + * whether mem_alloc_profiling_enabled() or not now. > > This comment does not explain why. I amended it in my suggestion below. I will follow your suggestion. > >>> + */ >>> + if (memcg_kmem_online() || slab_obj_exts(slab)) >>> free_slab_obj_exts(slab); > > free_slab_obj_exts() will be checking again that for > slab_obj_exts(slab) != NULL. Since this change effectively removes the > static key check (mem_alloc_profiling_enabled() call inside > need_slab_obj_ext()), I think we can simply make free_slab_obj_exts() > inline function and remove the above condition completely. IOW: > Got it. I'll send another version that includes these changes. > static inline void free_slab_obj_exts(struct slab *slab) > { > struct slabobj_ext *obj_exts; > > obj_exts = slab_obj_exts(slab); > if (!obj_exts) > return; > ... > slab->obj_exts = 0; > } > > static __always_inline void unaccount_slab(...) > { > /* > * The slab object extensions should be freed regardless of > * whether mem_alloc_profiling_enabled() or not because profiling > * might have been disabled after slab->obj_exts got allocated. > */ > free_slab_obj_exts(slab); > ... > } > >>> >>> mod_node_page_state(slab_pgdat(slab), cache_vmstat_idx(s), >>> -- >>> 2.25.1 >>> >>>