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 9CA37C001B0 for ; Mon, 24 Jul 2023 10:20:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 05C026B0071; Mon, 24 Jul 2023 06:20:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 00C8A6B0074; Mon, 24 Jul 2023 06:20:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E16316B0075; Mon, 24 Jul 2023 06:20:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id CFC656B0071 for ; Mon, 24 Jul 2023 06:20:08 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 98DF6C09E9 for ; Mon, 24 Jul 2023 10:20:08 +0000 (UTC) X-FDA: 81046110096.26.32B1CEB Received: from mail-il1-f181.google.com (mail-il1-f181.google.com [209.85.166.181]) by imf30.hostedemail.com (Postfix) with ESMTP id BC58380010 for ; Mon, 24 Jul 2023 10:20:06 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=U467ozCb; spf=pass (imf30.hostedemail.com: domain of glider@google.com designates 209.85.166.181 as permitted sender) smtp.mailfrom=glider@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690194006; 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=yb68c7xn9auyyAwnS5BdoaVit3QpNWbkekgLfdXJeds=; b=VpICZZON3Ju2A6It/9Bs11YF4fqJQbSfQoiARxq31Qngi+7ky3JGqA+rPrDLGQSsFhy20B c0pgEs8+xJrDCsGYGPykn90aYFJTTfVABWB3kPx4X6Mix3K2flMqtMkHBU8laCry4zz/zk w5sf/NrVJFnOzqVinQKHb++X1IVBZAk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690194006; a=rsa-sha256; cv=none; b=V4YtZ77TvOEWoKAwHMgTZo7W853228e6zQ1Tz5/6cl2nVPwQEYoc8R5ikj08oHoPrMmZyy SbX4P3TGxSa0H4ooICPHMFCOSXH2CIYLQh7eSNp1flwE2PkelNobeLtNj6wpKj4SDEXdnx fzJCGgZts0v4zMHOGSNgveB6kt8lFeI= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=U467ozCb; spf=pass (imf30.hostedemail.com: domain of glider@google.com designates 209.85.166.181 as permitted sender) smtp.mailfrom=glider@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-il1-f181.google.com with SMTP id e9e14a558f8ab-348c47ca963so4507935ab.0 for ; Mon, 24 Jul 2023 03:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1690194006; x=1690798806; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=yb68c7xn9auyyAwnS5BdoaVit3QpNWbkekgLfdXJeds=; b=U467ozCbf7zF3TYiFZZviMzXcG7zPJqXOginBD2Hi8sjoUeaon84QbSMjyO5IBac0S 9HM/LzcpblLGbMxTvo6U9Gzg+Xkb5Cw5n8uFKint3eJnG8hgu+0IR3/81pfiSlw/viv1 +VjNyfOqWM8Y2mrD+Pq9toGWCiQ+UluLY/SgEUrEsQdHqIhFUcnMp0XYF7rwhDeW3+sJ ceuZPNdXnv2+jx0Gbwr9eO3ZyaTyJe6avwMOzpgtR9Qn5+JqjowLBXpMq+e9pYI3a/mJ bYbTTZlTvxK+oVJnyNTTzzQX/cALNUVGa5uVJp4R1xn4SpwdBplHyZ8yXqrRVYurrG4D C/oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690194006; x=1690798806; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=yb68c7xn9auyyAwnS5BdoaVit3QpNWbkekgLfdXJeds=; b=klPg+U+GMcgcZirSbVO+nYR7cEFW4JEOYh2KyF1Bb3iZ7ANEl7ne5jUbSYiOxMjsvR sp0+ac9PTdRFF8/hqZJVD5E43tXhQ+SKUv3sRH+tXn2N/yJNGwtm2neKOS4NL6OTA6WE HHSdyW1xBne6K/74pKUYnUI6kKysl7EtbgeZvdL8EoNYPfM9ByyM4c70M93dMdtQoJ4B nnWTfbsZf8YD8LcJT0lVqGjYhK5JWYtLXIDKX+yMNC0kki3kOHL7cPVk98fks9CKWn55 bPbiCM68O+RhfsGqXojr+bVPvYvFKMzQgsV8jg7QBrCTDuAksIwyUsyHgGxqUl/P4bBz nrnw== X-Gm-Message-State: ABy/qLaVtqswXx8Yt4fzOdUAoMm2YtelI2AiwawbHbBzOuFHGlHyws8p ReFAMp+miSKOLH4YDY28LHsTzc9AjytoG2jvdAscKQ== X-Google-Smtp-Source: APBJJlEfng1J/r543cABdFhRK+zZ7LXgTHpQFFzc/jLrcdtRq67W7Pl2NfWOD6hfLOO7lBSI6Ea92WdJ4lN7K/jqmI8= X-Received: by 2002:a5d:8941:0:b0:786:ea57:22e2 with SMTP id b1-20020a5d8941000000b00786ea5722e2mr5748913iot.20.1690194005742; Mon, 24 Jul 2023 03:20:05 -0700 (PDT) MIME-Version: 1.0 References: <20230721160528.800311148@linuxfoundation.org> In-Reply-To: From: Alexander Potapenko Date: Mon, 24 Jul 2023 12:19:29 +0200 Message-ID: Subject: Re: [PATCH 6.4 000/292] 6.4.5-rc1 review To: Linus Torvalds Cc: Naresh Kamboju , Muchun Song , Marco Elver , Roman Gushchin , Andrew Morton , Linux-MM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: BC58380010 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: ynqzhmmhssbwnymjg849amhzcczj56hz X-HE-Tag: 1690194006-14051 X-HE-Meta: U2FsdGVkX1+4NQNHJ0E6acpy+R6MC7b7MFuC9k2cx4HOAH02bEG/XXdTyhYHXmCgTUldBac5W979loxEfOREHEOqFJrkTpTUV7XoHMMJfeIXEi6bS+XFS56wR/S5raE2LabTyV3xBlk5fkb6rCBAA5Tv9VmSeNaxv2mXhqUrMm0BoUWcjviZegQhNN/i8RfU55ju7mmmrR9c7WsqZgN+cADJkMRl1aG0KvTGITYpJcDNAOYAUWCgk842zlBssYoaIpmiloQYlTQcPIDPs2fFNUeZHB69YG72S3d+NmKHVCB0R6biH2Rz+8/Iyk2Ie/SIUUL7AeCu219OhXhRYfTQmCBWMq6EiTQtYk4owGDWxFgwKBh5hDldG1fn/h6nmbu5tDS2/dVyiF2DplMdU89DCI+4TBin15KlqPfaTcONofryKqs3OzEMQOCgWNjQCv8VUl6kQvSeWVRdPaPp4WeSWaOTdei7bq0J+S6OSpe2VjsQPpTYFzPDuzb0IDaxIpIH2Fj70BdceQCZimtFkL5fn3fayCB8xdtaVJaYvENbUspvDzCOwwBsFi6jS1NVbaCSutNYlIJBaLOVxM4m58JjLn2pC9guaMl4gJH/SM8vJVon7OKxPqY7yzkGHZb/baec2fk/GLWJ2YmBctCb+2vwXVNQTY/U+pNlkFoNRu1tDZS3kfF3j3Yxlbj2UlkdTYk4FNmlhuHNogya9sFuzL4NoFhv6/pW/CT1ki69MBHBBaB4DL/1gToM7PkMN4ntpmrZ9QxePT9Uwq2mMWGvHGKAngqJ/3wayj/dJ/OCVTlj3DOcftPleGm1L09lGDs8Dj5vlQPJjBPSilt3j/FIxMe56bz7vRroHxXtq/UvRCViGNU50Hr6sGyr5mI7FyGVIR5sYLbBxsLGjU44IpWUnasZuJQteFu2zRZ8wIjLG/RgtCFtFylKFF6eh/HmilLDRIg5HZAqQ8BI/Y8wVD9IUSB ow1/hwkp UJzlTBCCTtRalABEqstZqG6TDIQRkSgcrpkUoCNCUPi2vC8YInwZCC6SmqD7sR+JnYy61EhgASRUAGxsWR5ZVn90XEWx+NLDWxTgXeDoBoAT+dzw+4FcTqIxTB+sq9OpKHT8jNGBSl59gao7+h4UezSwBjjmwDoSIQwEQZGVlxoiOouEGhewkOCY2WGdK2Ar5vSJxAe+YypBkw2NmulfaX45Tz0Znoy4uFhgkBLn8zHpNsKUtnwu/fN580qBwEnsuWtvF8tRmCVvZJJzkiw+J+vBCBKNfldd2ZxY9hMyghsOmbufKn4ARwWVVhySYlmqx8sNjW5d5WJyzR0XvkDG8TOtJzgVuSAKXFqJZBilIlepjTyg= 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 Sat, Jul 22, 2023 at 6:37=E2=80=AFPM Linus Torvalds wrote: > > [ Removed the stable reviewers, bringing in the kfence people ] > > See > > https://lore.kernel.org/lkml/CA+G9fYvgy22wiY=3Dc3wLOrCM6o33636abhtEynXh= JkqxJh4ca0A@mail.gmail.com/ > > 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. > > Anybody? > > Linus > > > NOTE: > > The following kernel warning was noticed while booting qemu-arm64 > > with these configs enabled on stable rc 6.4.5-rc1. > > > > CONFIG_ARM64_64K_PAGES=3Dy > > CONFIG_KFENCE=3Dy Is there a full config somewhere? > > This crash is not easily reproducible. CONFIG_KFENCE_SAMPLE_INTERVAL=3D10 CONFIG_KFENCE_NUM_OBJECTS=3D2048 might improve reproducibility. > > > > boot logs: > > -------- > > [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x000f0510] > > [ 0.000000] Linux version 6.4.5-rc1 (tuxmake@tuxmake) > > (aarch64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils > > for Debian) 2.40) #1 SMP PREEMPT @1689957802 > > [ 0.000000] random: crng init done > > [ 0.000000] Machine model: linux,dummy-virt > > ... > > [ 0.006821] kfence: initialized - using 33554432 bytes for 255 > > objects at 0x(____ptrval____)-0x(____ptrval____) > > ... > > [ 7.726994] ------------[ cut here ]------------ > > [ 7.727704] WARNING: CPU: 1 PID: 1 at mm/kfence/core.c:1097 > > __kfence_free+0x84/0xc8 > ... > > [ 7.746478] Call trace: > > [ 7.746776] __kfence_free+0x84/0xc8 > > [ 7.747134] __slab_free+0x490/0x508 > > [ 7.748063] __kmem_cache_free+0x2b4/0x2d0 > > [ 7.748377] kfree+0x78/0x140 > > [ 7.748638] single_release+0x40/0x60 > > [ 7.750664] __fput+0x78/0x260 > > [ 7.751065] ____fput+0x18/0x30 > > [ 7.752086] task_work_run+0x80/0xe0 > > [ 7.753122] do_notify_resume+0x200/0x1398 > > [ 7.754292] el0_svc+0xec/0x100 > > [ 7.754573] el0t_64_sync_handler+0xf4/0x120 > > [ 7.755559] el0t_64_sync+0x190/0x198 It would be interesting to see the contents of /sys/kernel/debug/kfence/objects together with the object address. Would it be possible to boot the kernel with no_hash_pointers and add a line printing the object address: diff --git a/mm/kfence/core.c b/mm/kfence/core.c index dad3c0eb70a01..23f27f6cb18cf 100644 --- a/mm/kfence/core.c +++ b/mm/kfence/core.c @@ -1094,7 +1094,10 @@ void __kfence_free(void *addr) struct kfence_metadata *meta =3D addr_to_metadata((unsigned long)ad= dr); #ifdef CONFIG_MEMCG - KFENCE_WARN_ON(meta->objcg); + if (meta->objcg) { + pr_err("ADDR: %px\n", addr); + KFENCE_WARN_ON(1); + } #endif /* * If the objects of the cache are SLAB_TYPESAFE_BY_RCU, defer free= ing , and then dump /sys/kernel/debug/kfence/objects? Knowing the kfence pool location (the line starting with "kfence: initialized") and the object address, we can probably understand from the allocation stack in sysfs, whether the object is supposed to be deleted.