From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f194.google.com (mail-pf1-f194.google.com [209.85.210.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C17FC37DEAF for ; Wed, 27 May 2026 03:29:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.194 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779852576; cv=none; b=L6E2hX+MaHZPaqOpJh+HIwY11UlTAI7qhXS5bwa9ctNLAByH2TexX14ZMOPWjxZ+tbbREehOnKoA+OGl1LkTWDZgsuXMRUOQL74rAEeqSoyR5TU0epdNGGE35+avsxGI1oLyo6ZUyLjf4QC3ZSAh2jijIuI/ISIN7GkHIowIJtI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779852576; c=relaxed/simple; bh=NbPPm51uUAHAnIIFUegQN+gxWwVGNmdlYb+vntB/5X8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=VsrZJvSIFXYCYlxoiupD7OxIWV5sQpd9rEF8uIBPMRGBQ6J+CkZJhJzfSVEDXi7kImtbNC2iHSAJtrQ0MeEDDyzBqgCPxgVS1Vnv+4G0wzQphWC3yq/zqS1im60rdCwvjPzjUnjl4kGjmJ9pW+QsAyBBn3ZYQagE9zkynXbEuLs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Y7IlvtWc; arc=none smtp.client-ip=209.85.210.194 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Y7IlvtWc" Received: by mail-pf1-f194.google.com with SMTP id d2e1a72fcca58-83538fbd0b2so4588169b3a.0 for ; Tue, 26 May 2026 20:29:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779852571; x=1780457371; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=NK9+MAufae3OUHglq3BxF1m5jq3s3djB2nPaLW09hjI=; b=Y7IlvtWcAvy9uiZ3DAQlPNmn55dGBpwP6bSacQTbLsy1jQU4ZdC+32tVLcXFDitjKY ifet8fRQjhbfdrMyVIWvO511Dn+ta6ZB4jJSijXD9hDWeQD8qtFmuM3FjPHNAd2AZfOG NUMQ09aDlY6GxPz74KGibk99PV6YbNIJ0U4qmL2HBOlHvsJndfQfQVL+YAa+BKi7D/FM a/LEALmbn6uUcyNNBO9ipF4cTlN7ILtI4G51cucvx0AQ9qajoouZezNwlBn/rbTiL7Zg v39aSB61XlQPTpSD/WzO0Lsfy8DBC9rWy0OGXObv+93oj+O7UvhwfvKguIsMe/ezeTUt j+ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779852571; x=1780457371; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=NK9+MAufae3OUHglq3BxF1m5jq3s3djB2nPaLW09hjI=; b=aIE6Y0J0TZRdAJcOGeTY9ZyCkNHsHqLLL4KlmA8HJMg5eJRYBgxHitDAb9k72tysCa 3j7U0CuGOyr2ELYyYh4wBOmqk3Vwv5+SxeUH4t0FmAWhBcV6wYhqbgR3nMYnIw6Si7NA japUhF9k3fnaIKh+73BG1HTmw+p69dSU5xtkjyB6dMDFR/ngZAR4q5TQwmcBuJftgeeG MmYEeyyHda1dVlcwnA2C01s5fNAakpAMmpA3e+GDBOnuCctVJx0pObQXZg8cXJheWt1R kdQ8m8UAdA3sI8EBFbxvFmJjqKuVfV7+3B4W1sDj09pgpnlCVZCRAx/DjQUGOcyLWuKx kZUg== X-Forwarded-Encrypted: i=1; AFNElJ9kWQ56twGucfgLRCpV1it3/DbCZYvyvxjR8pYMOo4O/RXZ6F2GGO/8iVDsgr0jf8I+uvSXdj237s/XiH0=@vger.kernel.org X-Gm-Message-State: AOJu0YwX6GFUVuMWx2P3foHgM70Y2oTdjKvkJXFAXECc6Bqqm9dlUApT gYgSDcPIUUdjltGy3sw9I4XstEODsYDf5EfF86kPuh5b6+LdVur2eB05o8st9doPGrnpCQ== X-Gm-Gg: Acq92OENHf0I/CyK2wLCfUVRDI9RG1TqWcFEJi9RaR7uE4klLJDqZmylu4n51+D1VDX g+ns/sl3vXu5iw1am0Q4JJKym6DnOpz0Bs+XUjZxOU5f6z1tWFiufuqOcDwP4DxZo3YYn0r1v13 lOakoI75e7qN1ej7slOC/4gioPoy/opl82lQmH0D51IcxP5eJNrxRz18y8SX2kFv7V/oPlZz7Ax +R68/BK+swwxRjSulnSGIYxEVfQsAxLBu4pyoZoN6VOkTwZCTzJIucEcngTUy4asQF3IG9Nx/2+ 5lVmmRTF9Gp9rVX3vZJMKNtrK2Y3jCFElT2AHHwqfRnUz25cqJePTraJlU7Yrh2IegrHWz99SVa 8Vp4O0spiByJLVuxKc1zUQ1qPaAqQ24u96UCmsng+Fml1YvERhuxYF3jlBA0Crs/9CSYf1B+6AM +ZtfUYoqsHsaEG7YugtZRMFV3Pl4/2+vjkQ0Z0Dg8PKy8vzBE= X-Received: by 2002:a05:6a00:4f94:b0:82c:6da7:2d3d with SMTP id d2e1a72fcca58-8415f3d0e36mr19286959b3a.11.1779852571354; Tue, 26 May 2026 20:29:31 -0700 (PDT) Received: from intel.company.local ([210.184.73.204]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-841d7307596sm749688b3a.59.2026.05.26.20.29.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 May 2026 20:29:30 -0700 (PDT) From: Wandun Chen To: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, loongarch@lists.linux.dev, linux-riscv@lists.infradead.org, devicetree@vger.kernel.org, kexec@lists.infradead.org, iommu@lists.linux.dev, zhaomeijing@lixiang.com Cc: catalin.marinas@arm.com, will@kernel.org, chenhuacai@kernel.org, kernel@xen0n.name, pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr, robh@kernel.org, saravanak@kernel.org, akpm@linux-foundation.org, bhe@redhat.com, rppt@kernel.org, pasha.tatashin@soleen.com, pratyush@kernel.org, ruirui.yang@linux.dev, m.szyprowski@samsung.com, robin.murphy@arm.com, quic_obabatun@quicinc.com Subject: [PATCH v3 00/11] kdump: reduce vmcore size and capture time Date: Wed, 27 May 2026 11:29:06 +0800 Message-ID: <20260527032917.3385849-1-chenwandun1@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Wandun Chen On SoCs that carve out large firmware-owned reserved memory (GPU firmware, DSP, modem, camera ISP, NPU, ...), kdump currently dumps those carveouts as part of system RAM even though their contents are firmware state that is not useful for kernel crash analysis. This series introduces an opt-in 'dumpable' flag [1] on struct reserved_mem and uses it to filter the elfcorehdr PT_LOAD ranges on DT-based architectures (arm64, riscv, loongarch). By default reserved regions are treated as non-dumpable; CMA regions are explicitly opted in because their pages are returned to the buddy allocator and may carry key crash-analysis data. The series is organized as follows: Patches 1-3: Pre-existing fixes and a small prep change. Patches 4-5: Restructure to allow appending /memreserve/ entries. Patches 6-7: Add a dumpable flag and append /memreserve/ entries. Patch 8: Add generic kdump helpers. Patches 9-11: Wire the helpers into arm64, riscv and loongarch kdump elfcorehdr preparation. v2 --> v3: 1. Fix out-of-bounds issue if device tree lacks /reserved-memory node.[2] 2. Fix UAF issue when alloc_reserved_mem_array() fails. 3. Add some prepare patches. v1 --> v2: 1. v1 added an opt-out DT property ('linux,no-dump'). Per Rob's feedback [1], v2 drop that property and exclude reserve memory by default. 2. Split some prepared patches from the original patches. 3. Address coding-style comments on patch 5 from Rob. [1] https://lore.kernel.org/lkml/20260506144542.GA2072596-robh@kernel.org/ [2] https://sashiko.dev/#/patchset/20260520091844.592753-1-chenwandun%40lixiang.com?part=4 Wandun Chen (11): of: reserved_mem: handle NULL name in of_reserved_mem_lookup() kexec/crash: provide crash_exclude_mem_range() stub when CONFIG_CRASH_DUMP=n of: reserved_mem: avoid post-init UAF when alloc_reserved_mem_array() fails of: reserved_mem: zero total_reserved_mem_cnt if no valid /reserved-memory entry of: reserved_mem: split alloc_reserved_mem_array() from fdt_scan_reserved_mem_late() of: reserved_mem: add dumpable flag to opt-in vmcore of: reserved_mem: save /memreserve/ entries into the reserved_mem array of: reserved_mem: add kdump helpers to exclude non-dumpable regions arm64: kdump: exclude non-dumpable reserved memory regions from vmcore riscv: kdump: exclude non-dumpable reserved memory regions from vmcore loongarch: kdump: exclude non-dumpable reserved memory regions from vmcore arch/arm64/kernel/machine_kexec_file.c | 6 ++ arch/loongarch/kernel/machine_kexec_file.c | 6 ++ arch/riscv/kernel/machine_kexec_file.c | 4 + drivers/of/fdt.c | 11 +- drivers/of/of_private.h | 3 + drivers/of/of_reserved_mem.c | 117 +++++++++++++++++++-- include/linux/crash_core.h | 6 ++ include/linux/of_reserved_mem.h | 15 +++ kernel/dma/contiguous.c | 1 + 9 files changed, 157 insertions(+), 12 deletions(-) -- 2.43.0