[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CAOU40uBFoDg4F2Xrqg2ABJOJXV1QsyzOXv7tvA3M6hmE8b=PQA@mail.gmail.com>
Date: Tue, 27 May 2025 11:15:00 +0800
From: Xianying Wang <wangxianying546@...il.com>
To: linux-kernel@...r.kernel.org
Subject: [BUG] BUG: scheduling while atomic in stack_depot_save_flags
Hi,
I discovered a kernel crash described as "BUG: scheduling while atomic
in stack_depot_save_flags". This issue occurs in the function
stack_depot_save_flags (lib/stackdepot.c:676), which is invoked during
memory allocation via mempool_alloc in the block I/O request handling
path. The crash is triggered when the system attempts to schedule in
an atomic context due to a failed memory allocation.
The call trace indicates that the crash occurs within the kworker/0:1H
thread when processing I/O via the blk-mq layer. Specifically, the
blk_mq_run_work_fn function dispatches a SCSI request, which calls
into scsi_alloc_sgtables. This function uses a memory pool, and its
allocation path eventually invokes stack_depot_save_flags, likely
through KASAN instrumentation.
Preliminary analysis suggests that this crash may be triggered when
the system is under constrained memory conditions. In my test case, I
manually increased the value of /proc/sys/vm/min_free_kbytes to an
extremely high value (0x7fffffff) before triggering the I/O. This
likely prevented GFP_ATOMIC allocations from succeeding, causing
fallback logic to attempt sleeping, which violates the atomic context
constraint.
This can be reproduced on:
HEAD commit:
commit e8f897f4afef0031fe618a8e94127a0934896aba
report: https://pastebin.com/raw/1Rc6hMYx
console output : https://pastebin.com/raw/c0aR0Vcw
kernel config : https://pastebin.com/raw/aJ9rUnhG
C reproducer : https://pastebin.com/raw/43sWwB08
Best regards,
Xianying
Powered by blists - more mailing lists