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 AEEA9C0015E for ; Mon, 24 Jul 2023 12:10:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C91B38E0001; Mon, 24 Jul 2023 08:10:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C42576B0075; Mon, 24 Jul 2023 08:10:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B3C036B0071; Mon, 24 Jul 2023 08:10:36 -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 A5EED6B0071 for ; Mon, 24 Jul 2023 08:10:36 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 7EFE21209A7 for ; Mon, 24 Jul 2023 12:10:36 +0000 (UTC) X-FDA: 81046388472.25.EB3E0B4 Received: from mail-vk1-f179.google.com (mail-vk1-f179.google.com [209.85.221.179]) by imf18.hostedemail.com (Postfix) with ESMTP id 9E6C31C0019 for ; Mon, 24 Jul 2023 12:10:34 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b=IN33TFEP; spf=pass (imf18.hostedemail.com: domain of naresh.kamboju@linaro.org designates 209.85.221.179 as permitted sender) smtp.mailfrom=naresh.kamboju@linaro.org; dmarc=pass (policy=none) header.from=linaro.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690200634; 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=nEQfF1Eo4RKmrJVoRoMsvpqtXY5ot1htFg2NKu84kv0=; b=XScgdkPDKWVI5KLWUAyuuZ3758neBfBHnbd6hQEzhSjuRXKO3cvUfUoHuiDiqbPuo2I2wN 6IhWMWIblzPJU5QCk6EpGWD7nYYhwhj98vi9Uo2gmM8c+5GGAHou7fk0rtzZSKxHZr4bqp YQHumDeQc+oFa4FyRIw3Q/+4FpEUMuM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690200634; a=rsa-sha256; cv=none; b=XuePYrrbYc4UcRntxp74yc3AusvtID4u8BNqxwAw3TuF5UJsestYjuf8i9WF1NMzfLSTFe V5gQgFeY7Zhu/H9RtasqF5s0f+9x5GUrfm46WaNNz9NGA7NmXbRIu9vN83vpltZD7apgoE RPLX1GBRNy4zNLcBFpvKQOFwEpYok6I= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b=IN33TFEP; spf=pass (imf18.hostedemail.com: domain of naresh.kamboju@linaro.org designates 209.85.221.179 as permitted sender) smtp.mailfrom=naresh.kamboju@linaro.org; dmarc=pass (policy=none) header.from=linaro.org Received: by mail-vk1-f179.google.com with SMTP id 71dfb90a1353d-485e9849e7cso535106e0c.1 for ; Mon, 24 Jul 2023 05:10:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1690200633; x=1690805433; 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=nEQfF1Eo4RKmrJVoRoMsvpqtXY5ot1htFg2NKu84kv0=; b=IN33TFEPb7rvhNd3yii68DCCf5D9kxgH/0Bi+hom5X1un+PbBNLwm5hgYSvIwEDbJ0 k6V06gdlfmiP0yWKtb3kMC+E7KfTNODIU0aMrHdoEUphXceSo0pxEcJo6ob1iREuClsd Bw/f8Y4E4SK2PrKCV8Qn/MA2SQs5Xz13A16lK+S5/PM7GI9PLFiClwFGMJzpKSwm+LYN nrMLtxIGOHBcP1JaiqDUyxPqmsZOSSInQI7tny+Vcz/HthJB/1tUHXctC6kUaUP6GXjv x5NFXbViO9ylzVx/eyeBnF99xcsXAeQJxl2NpYSSWX+JoLWiktaJVQwCSvJBNf2VXgef 6LdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690200633; x=1690805433; 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=nEQfF1Eo4RKmrJVoRoMsvpqtXY5ot1htFg2NKu84kv0=; b=B+IKVt6AgF09XG9uEkdLg1x4BVRbU/97G7BiWI8DuaCBK+0fF+/UrKpq/Fir/G0RKO 0l8NsWx0YOyaO+WHWcdV31Hxpw1v1kWwzDkdm/bRWHqrTOqp8KGuMJW5JntuvXfXARzm fw0mRUx28z8Se/sZyTaRk4BOOnqUL7tNLT4GiH2RS9Wgyff32vg3eLXu20JynYjsglO+ qgoHKFP+Iuygg4AbeAvf1BGlDFdOEb+ilQ2nKmh3VWQTL2BWNGDaJ7zuV/tl+vfMI9g9 UAZEMFDEaImCY8x7bflBn2xbGwvojhNgnDpt2ypAKiIASLVYeQwF4mT8zeH4V8ni0ZZB GiRQ== X-Gm-Message-State: ABy/qLYEEaWbX/9OGPzKk+fD0+44ZAFzmWF96xOGMbDUcNROXF4ZEQ5B WIhOGXonVN1g9gtT/xw8lb/006CqItBzRGJSHUAaTQ== X-Google-Smtp-Source: APBJJlEb/OyolW+E38q4GIq2meWA5zsBKjZ3dKiTzXtE+yI+HTU6C7N4gPyTSOntl4+c5Ng9BgH/9wjtXFHCWEGiMEg= X-Received: by 2002:a67:f58f:0:b0:443:3e1f:7e00 with SMTP id i15-20020a67f58f000000b004433e1f7e00mr2672247vso.6.1690200633348; Mon, 24 Jul 2023 05:10:33 -0700 (PDT) MIME-Version: 1.0 References: <20230721160528.800311148@linuxfoundation.org> In-Reply-To: From: Naresh Kamboju Date: Mon, 24 Jul 2023 17:40:20 +0530 Message-ID: Subject: Re: [PATCH 6.4 000/292] 6.4.5-rc1 review To: Alexander Potapenko Cc: Linus Torvalds , Muchun Song , Marco Elver , Roman Gushchin , Andrew Morton , Linux-MM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: xu56crqiookr93anu6au4ztzborkfdnh X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 9E6C31C0019 X-Rspam-User: X-HE-Tag: 1690200634-343486 X-HE-Meta: U2FsdGVkX19LCGuOxpuT7cBKI9HdCMtU9y0mefCu09dpjcwC6Z0FmMrLF06w96y7yAUlXCWhsV7GavMHd1NmvX4B4yxGWV8sB9ffckOy+sQmwCSNPE19iJMSInUNZ0Sz2ydql74zaxlqO7itMiA935tlKeKa4EJlyrstxJatghV4607tQ1q6z0Xz1BjNDktEHVtcdLP9yV6Ch7KlPtOw8oqfipjCFbeCcABuqmP1vzzqFZdQ+zwcaIh8m1cZg0xCyeb0GqN2r9my7fNzjutlXvyVVCy1Bi7lD4J/A7SdgbsqmiswCOFv6YTtKfVQFPANxku42T6yoydFFMTl4w51Q5SUg5GM2oNqMl/1giDWXlDP7fuewEHIL64K+QtqI7EE8ELwEzi3PEtgmz8/cUucDF/O8N28DFC/KOfgi97QSu5ELdVHJMrJSmdl/xNScc4mV18CMHnTFHZnJob2IB50Bp/SRIZ3Gu6sYbUCGqQ80KDEjqQF7ge/wo+8Vxh6dN6vDj02y3m7LFsDKSfT7oVYgn/2fvaJx4+O3pbI3MGqXZqOvo5493Cxvu7drxxlytv5aULNvNunbVIbPcSzuAWCuhWkMkyQKcm+TuB3oUSiz5dQmE9hWtvz3IM8Th+c1ND5aB8teJa+HQ6/kzzv6RWBFnOBzRQW/xbVLd0yfmTplVv6BM5rYO7eNyiFxUkZFNfxcLE7rlEViGNDZbzHr7bcgEbVZYbQQOhkV+SmscWDWhQ9fZ5hXnolqC5v2pB9gAuKhqPe5Vsb1qzzm8kULS/8Aevks3bIy/6ysgh2frbrhTm0ecmdtUB3j81kz+D8gz8IlTBj3TJYgETZtR2fV7SoX2quNRPUkoZa6W4Od28a21pXM6NtXANSDjbaPdeiIqhk8uvmHb4fxqpZUw23f2lcclgTJm+ZW0FTeKt8s9twN0CYgUC3QjPpX79gCtosq4/MSchrFhe/YDz/U+jTZ+w puWotdeO HSrQWPvKGeXeLDGZ7FOpT62XzUcjm5O/aXCNedn5StA27ITFkh7MS8nMm2GZPWgfvmxjNRPP7120b4XzQSmbDAU/FF3YMFGvR/onOSaLWh2+yBNmoeicv2V4nCJEbNTRp8+VQcsIDhMS3UJAHdBeMRuE4H8vn2WGrcJ5evOt+6ll8WzTDQ6jKk60S02UTpN8nLCwv13gKzLGJXDAuLQDnNwYAI71VUtvuZp72LbaHqLly6HQkjUXKX+1Gu6858oxEVoDKaio7f/3C46ls1prWmesU3QS6JChMEZYu65w98pW54MCp+V+PMeBjb704zIKkPDOpCy6IX/5D1CntcP8Fgrt2buwIOFwE55rLNi+gGxKPLxcykcHtxQWkY8Ixy+cdXqFt7Rfsi5i7z6SmLr7RrlIhchjDysp/ZEfzfbhB5T2wKwdmsggExT0FDxqkXqmBHBUo 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 Mon, 24 Jul 2023 at 15:50, Alexander Potapenko wrote= : > > 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=3Dc3wLOrCM6o33636abhtEyn= XhJkqxJh4ca0A@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? Please find build details - https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu= 8fIxjexhnM/ - https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu= 8fIxjexhnM/config - https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu= 8fIxjexhnM/vmlinux.xz - https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu= 8fIxjexhnM/System.map - https://storage.tuxsuite.com/public/linaro/lkft/builds/2StEPFnEfoD076PRu= 8fIxjexhnM/Image.gz > > > > This crash is not easily reproducible. > > CONFIG_KFENCE_SAMPLE_INTERVAL=3D10 > CONFIG_KFENCE_NUM_OBJECTS=3D2048 > > might improve reproducibility. The above test have following Kconfigs enabled. CONFIG_HAVE_ARCH_KASAN=3Dy CONFIG_HAVE_ARCH_KASAN_SW_TAGS=3Dy CONFIG_HAVE_ARCH_KASAN_HW_TAGS=3Dy CONFIG_HAVE_ARCH_KASAN_VMALLOC=3Dy CONFIG_CC_HAS_KASAN_GENERIC=3Dy CONFIG_CC_HAS_KASAN_SW_TAGS=3Dy CONFIG_CC_HAS_WORKING_NOSANITIZE_ADDRESS=3Dy # CONFIG_KASAN is not set CONFIG_HAVE_ARCH_KFENCE=3Dy CONFIG_KFENCE=3Dy CONFIG_KFENCE_SAMPLE_INTERVAL=3D100 CONFIG_KFENCE_NUM_OBJECTS=3D255 # CONFIG_KFENCE_DEFERRABLE is not set CONFIG_KFENCE_STRESS_TEST_FAULTS=3D0 > > > > > > > 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 Binutil= s > > > 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)= addr); > > #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 fr= eeing > > , and then dump /sys/kernel/debug/kfence/objects? > This testing is running on CI loops and however, I will try to reproduce this locally. > 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. - Naresh