From patchwork Wed May 5 20:06:07 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Waiman Long X-Patchwork-Id: 12240941 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 84AA1C433ED for ; Wed, 5 May 2021 20:06:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2B0C7611AC for ; Wed, 5 May 2021 20:06:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2B0C7611AC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id AA7046B006C; Wed, 5 May 2021 16:06:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A44A96B006E; Wed, 5 May 2021 16:06:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8BE696B0070; Wed, 5 May 2021 16:06:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0063.hostedemail.com [216.40.44.63]) by kanga.kvack.org (Postfix) with ESMTP id 6B9B36B006C for ; Wed, 5 May 2021 16:06:40 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 0B00E87CC for ; Wed, 5 May 2021 20:06:40 +0000 (UTC) X-FDA: 78108260160.30.A70E35B Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf23.hostedemail.com (Postfix) with ESMTP id 1F67DA0003B8 for ; Wed, 5 May 2021 20:06:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1620245199; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=JUmGq2wlaOeze3MXhpw6Yda3Y4YIjTKC44x0gDwnWr8=; b=BRvbfE4NJaCRq2Eg2RlHMirR/wrFOsXAaMnUXM/Zm8lO1RzgiahgTDTGcHiC1c3YEk9yuJ i044HOpMLuV+fz78uH9lrz9To1Vwubq7XH48HPQiTt3S7qpbsbeHeg6DJmzZrM7GZJ3ash 6nR2VYN0kpV0DIU9DpuO5S9gjnCMwSs= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-147-JAddeHJ5On-KhEpdV2Purg-1; Wed, 05 May 2021 16:06:37 -0400 X-MC-Unique: JAddeHJ5On-KhEpdV2Purg-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3A6DB107ACED; Wed, 5 May 2021 20:06:35 +0000 (UTC) Received: from llong.com (ovpn-117-4.rdu2.redhat.com [10.10.117.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id D7C5710016FD; Wed, 5 May 2021 20:06:29 +0000 (UTC) From: Waiman Long To: Johannes Weiner , Michal Hocko , Vladimir Davydov , Andrew Morton , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Vlastimil Babka , Roman Gushchin , Shakeel Butt Cc: linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, Waiman Long Subject: [PATCH v4 0/3] mm: memcg/slab: Fix objcg pointer array handling problem Date: Wed, 5 May 2021 16:06:07 -0400 Message-Id: <20210505200610.13943-1-longman@redhat.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=BRvbfE4N; spf=none (imf23.hostedemail.com: domain of longman@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=longman@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 1F67DA0003B8 X-Stat-Signature: 9zeko4pwtnkrs7wdksp75qioo8setzje Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf23; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=216.205.24.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620245192-620570 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: v4: - Incorporate suggestions from others like setting SLAB_ACCOUNT for KMALLOC_CGROUP caches into patch 2. - Add a new patch 3 to disable caches merging for KMALLOC_NORMAL caches as suggested by Roman. v3: - Update patch 2 commit log and rework kmalloc_type() to make it easier to read. v2: - Take suggestion from Vlastimil to use a new set of kmalloc-cg-* to handle the objcg pointer array allocation and freeing problems. Since the merging of the new slab memory controller in v5.9, the page structure stores a pointer to objcg pointer array for slab pages. When the slab has no used objects, it can be freed in free_slab() which will call kfree() to free the objcg pointer array in memcg_alloc_page_obj_cgroups(). If it happens that the objcg pointer array is the last used object in its slab, that slab may then be freed which may caused kfree() to be called again. With the right workload, the slab cache may be set up in a way that allows the recursive kfree() calling loop to nest deep enough to cause a kernel stack overflow and panic the system. In fact, we have a reproducer that can cause kernel stack overflow on a s390 system involving kmalloc-rcl-256 and kmalloc-rcl-128 slabs with the following kfree() loop recursively called 74 times: [ 285.520739] [<000000000ec432fc>] kfree+0x4bc/0x560 [ 285.520740] [<000000000ec43466>] __free_slab+0xc6/0x228 [ 285.520741] [<000000000ec41fc2>] __slab_free+0x3c2/0x3e0 [ 285.520742] [<000000000ec432fc>] kfree+0x4bc/0x560 : While investigating this issue, I also found an issue on the allocation side. If the objcg pointer array happen to come from the same slab or a circular dependency linkage is formed with multiple slabs, those affected slabs can never be freed again. This patch series addresses these two issues by introducing a new set of kmalloc-cg- caches split from kmalloc- caches. The new set will only contain non-reclaimable and non-dma objects that are accounted in memory cgroups whereas the old set are now for unaccounted objects only. By making this split, all the objcg pointer arrays will come from the kmalloc- caches, but those caches will never hold any objcg pointer array. As a result, deeply nested kfree() call and the unfreeable slab problems are now gone. Waiman Long (3): mm: memcg/slab: Properly set up gfp flags for objcg pointer array mm: memcg/slab: Create a new set of kmalloc-cg- caches mm: memcg/slab: Disable cache merging for KMALLOC_NORMAL caches include/linux/slab.h | 41 ++++++++++++++++++++++++++++++++--------- mm/memcontrol.c | 8 ++++++++ mm/slab.h | 1 - mm/slab_common.c | 32 ++++++++++++++++++++++++-------- 4 files changed, 64 insertions(+), 18 deletions(-)