[<prev] [next>] [day] [month] [year] [list]
Message-ID: <960a1491-47bc-464b-a955-37d62470c0ef@linux.alibaba.com>
Date: Mon, 4 Aug 2025 17:49:07 +0800
From: Gao Xiang <hsiangkao@...ux.alibaba.com>
To: Junli Liu <liujunli@...iang.com>, linux-erofs@...ts.ozlabs.org,
linux-kernel@...r.kernel.org
Cc: xiang@...nel.org, chao@...nel.org, yangsonghua@...iang.com
Subject: Re: [PATCH v2] erofs: fix atomic context detection when
!CONFIG_DEBUG_LOCK_ALLOC
... the patch format is still broken, is your mail server
or your mail client broken?
On 2025/8/4 17:38, Junli Liu wrote:
> Since EROFS handles decompression in non-atomic contexts due to
> uncontrollable decompression latencies and vmap() usage, it tries
> to detect atomic contexts and only kicks off a kworker on demand
> in order to reduce unnecessary scheduling overhead.
>
> However, the current approach is insufficient and can lead to
> sleeping function calls in invalid contexts, causing kernel
> warnings and potential system instability. See the stacktrace [1]
... and previous discussion [2].
>
> The current implementation only checks rcu_read_lock_any_held(),
> which behaves inconsistently across different kernel configurations:
>
> - When CONFIG_DEBUG_LOCK_ALLOC is enabled: correctly detects RCU
> critical sections by checking rcu_lock_map
> - When CONFIG_DEBUG_LOCK_ALLOC is disabled: compiles to
> "!preemptible()", which only checks preempt_count and misses
> RCU critical sections
>
> This patch introduces z_erofs_in_atomic() to provide comprehensive
> atomic context detection:
>
> 1. Check RCU preemption depth when CONFIG_PREEMPTION is enabled,
> as RCU critical sections may not affect preempt_count but still
> require atomic handling
>
> 2. Always use async processing when CONFIG_PREEMPT_COUNT is disabled,
> as preemption state cannot be reliably determined
>
> 3. Fall back to standard preemptible() check for remaining cases
>
> The function replaces the previous complex condition check and ensures
> that z_erofs always uses (kthread_)work in atomic contexts to minimize
> scheduling overhead and prevent sleeping in invalid contexts.
>
> ==============================================
> [1] Problem stacktrace
> BUG: sleeping function called from invalid context at
> kernel/locking/rtmutex_api.c:510
> in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 107,
> name: irq/54-ufshcd
> preempt_count: 0, expected: 0
> RCU nest depth: 2, expected: 0
>
> Link: https://lore.kernel.org/r/58b661d0-0ebb-4b45-a10d-c5927fb791cd@paulmck-laptop
I prefer to replace the "Link:" to
[2] https://lore.kernel.org/r/58b661d0-0ebb-4b45-a10d-c5927fb791cd@paulmck-laptop
Since "Link:" tag mainly refers to the your current patch
in the lore...
Thanks,
Gao Xiang
> Signed-off-by: Junli Liu
> ---
> fs/erofs/zdata.c | 13 +++++++++++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/fs/erofs/zdata.c b/fs/erofs/zdata.c
> index 792f20888..2d7329700 100644
> --- a/fs/erofs/zdata.c
> +++ b/fs/erofs/zdata.c
> @@ -1432,6 +1432,16 @@ static void z_erofs_decompressqueue_kthread_work(struct kthread_work *work)
> }
> #endif
>
> +/* Use (kthread_)work in atomic contexts to minimize scheduling overhead */
> +static inline bool z_erofs_in_atomic(void)
> +{
> + if (IS_ENABLED(CONFIG_PREEMPTION) && rcu_preempt_depth())
> + return true;
> + if (!IS_ENABLED(CONFIG_PREEMPT_COUNT))
> + return true;
> + return !preemptible();
> +}
> +
> static void z_erofs_decompress_kickoff(struct z_erofs_decompressqueue *io,
> int bios)
> {
> @@ -1446,8 +1456,7 @@ static void z_erofs_decompress_kickoff(struct z_erofs_decompressqueue *io,
>
> if (atomic_add_return(bios, &io->pending_bios))
> return;
> - /* Use (kthread_)work and sync decompression for atomic contexts only */
> - if (!in_task() || irqs_disabled() || rcu_read_lock_any_held()) {
> + if (z_erofs_in_atomic()) {
> #ifdef CONFIG_EROFS_FS_PCPU_KTHREAD
> struct kthread_worker *worker;
>
> --
> 2.25.1
>
>
> 声明:这封邮件只允许文件接收者阅读,有很高的机密性要求。禁止其他人使用、打开、复制或转发里面的任何内容。如果本邮件错误地发给了你,请联系邮件发出者并删除这个文件。机密及法律的特权并不因为误发邮件而放弃或丧失。任何提出的观点或意见只属于作者的个人见解,并不一定代表本公司。
> Disclaimer: This email is intended to be read only by the designated recipient of the document and has high confidentiality requirements. Anyone else is prohibited from using, opening, copying or forwarding any of the contents inside. If this email was sent to you by mistake, please contact the sender of the email and delete this file immediately. Confidentiality and legal privileges are not waived or lost by misdirected emails. Any views or opinions expressed in the email are those of the author and do not necessarily represent those of the Company.
>
Powered by blists - more mailing lists