From nobody Sat Jul 25 19:28:42 2026 Received: from out30-100.freemail.mail.aliyun.com (out30-100.freemail.mail.aliyun.com [115.124.30.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9B57937E2F9 for ; Tue, 14 Jul 2026 11:13:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.100 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784027635; cv=none; b=T2NcOHKA3YPmdZG2K9y3Gb/UvblzFkVA7RA8r8d+KbVbzs3UmIUyQiiZ6RZiYwuh+cP3u3LgQ1K90MtPC+zVZFOiF3w4mK2o5gYiUOC/LWmas5L+LQQkijJODKgcVfli4hA3N9jhoQeoVZ2tYVBIlYzA+4GyXmVluf9pX0xpXkA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784027635; c=relaxed/simple; bh=daVZIyLSAwQWi3qqGaVpHaGvNP6YoVh5PKCIu5796GE=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=ev8Oe9bpRUio0YxjYP50IPMKbegTUuW9k6C3xqbiw/TSpUWzpu7TyXIe4jLOFzFwAltF32eZz3VlZpOPyVQmsNrPCI3JBSaXHn1lKEh9EnInK5DwHVXPFLheTeHXBSfw5Gqkdm2t58fPLGPvD7CHnR6nkjDxQ4JlfnWn5/COgN0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=Z37lHNEU; arc=none smtp.client-ip=115.124.30.100 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="Z37lHNEU" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1784027629; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=G05WrOMxjG6qbIAImoWU0O1f8YX/psvFHSY+lRyiXZk=; b=Z37lHNEUdMTcwbIY/rPdWmBof3B0DwclTbbr0bWIE5MiZ71LEYqddnEpc2879lwfiHiAJAremRlGzyhIO0wXJHhx2ub+K9V4JvIEx+vno19dxTik3tPZgbAdOevolBhdhb42EEtZhUDZydmik0nWYd+Ap/FBXS129FVYiVIrCYI= X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R131e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033032089153;MF=feng.tang@linux.alibaba.com;NM=1;PH=DS;RN=15;SR=0;TI=SMTPD_---0X74BvW4_1784027627; Received: from localhost(mailfrom:feng.tang@linux.alibaba.com fp:SMTPD_---0X74BvW4_1784027627 cluster:ay36) by smtp.aliyun-inc.com; Tue, 14 Jul 2026 19:13:47 +0800 From: Feng Tang To: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot Cc: Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak , John Paul Adrian Glaubitz , Thomas Gleixner , Andrew Morton , feng.tang@linux.alibaba.com, linux-kernel@vger.kernel.org Subject: [PATCH v4] sched/debug: Dump end of stack when stack corruption detected Date: Tue, 14 Jul 2026 19:13:45 +0800 Message-Id: <20260714111345.50501-1-feng.tang@linux.alibaba.com> X-Mailer: git-send-email 2.39.5 (Apple Git-154) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When debugging a kernel hang during suspend/resume [1], there were random memory corruptions in different places like being reported by slub_debug+KASAN, corrupted linked list or detected by scheduler with error message: "Kernel panic - not syncing: corrupted stack end detected inside schedule= r" Dump the corrupted memory around the stack end to give more direct hints about how the memory is corrupted, which could be cross-checked with the memory dump from other victims for root-causing. Something like: " Corrupted Stack: ff11000122770000: ff ff ff ff ff ff 14 91 82 3b 78 e8 08 = 00 45 00 .........;x...E. Corrupted Stack: ff11000122770010: 00 1d 2a ff 40 00 40 11 98 c8 0a ef 30 = 2c 0a ef ..*.@.@.....0,.. Corrupted Stack: ff11000122770020: 30 ff a2 00 22 3d 00 09 9a 95 2a 00 00 = 00 00 00 0..."=3D....*..... ... Kernel panic - not syncing: corrupted stack end detected inside scheduler " By comparing it with the dumped memory from other places like KASAN, the same data pattern was found, which was later used to check the data buffer of ethernet driver and got exact match. Then the culprit was identified to be ethernet driver, that it frees RX related memory back to kernel in its suspend hook, but its hardware is not really stopped, and still send data through DMA to (corrupt) those old RX buffer which is now used by different kernel component. [1]. https://bugzilla.kernel.org/show_bug.cgi?id=3D217854 Signed-off-by: Feng Tang Reviewed-by: John Paul Adrian Glaubitz Signed-off-by: Feng Tang --- Changlog: since v3: * Modify commit log and rebase against 7.2-rc1 * Update author info since v2: * Change code format (Adrian) * Add Reviewed tag from Adrian since v1: * Refine the commit log with more info, and rebase againt 6.8-rc3 kernel/sched/core.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 96226707c2f6..0bd898927047 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -6070,8 +6070,19 @@ static noinline void __schedule_bug(struct task_stru= ct *prev) static inline void schedule_debug(struct task_struct *prev, bool preempt) { #ifdef CONFIG_SCHED_STACK_END_CHECK - if (task_stack_end_corrupted(prev)) + if (task_stack_end_corrupted(prev)) { + unsigned long *ptr =3D end_of_stack(prev); + + /* Dump 16 ulong words around the corruption point */ +#ifdef CONFIG_STACK_GROWSUP + ptr -=3D 15; +#endif + print_hex_dump(KERN_ERR, "Corrupted Stack: ", + DUMP_PREFIX_ADDRESS, 16, 1, ptr, + 16 * sizeof(unsigned long), true); + panic("corrupted stack end detected inside scheduler\n"); + } =20 if (task_scs_end_corrupted(prev)) panic("corrupted shadow stack detected inside scheduler\n"); --=20 2.39.5 (Apple Git-154)