netdev - Re: [PATCH v1] net/sched: sch_qfq: Avoid triggering might_sleep in atomic context in qfq_delete

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <01463f6f-a45b-4122-a7cf-8fbf7889fd48@suswa.mountain>
Date: Fri, 18 Jul 2025 22:43:22 +0300
From: Dan Carpenter <dan.carpenter@...aro.org>
To: Xiang Mei <xmei5@....edu>
Cc: xiyou.wangcong@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH v1] net/sched: sch_qfq: Avoid triggering might_sleep in
 atomic context in qfq_delete_class

On Thu, Jul 17, 2025 at 04:01:28PM -0700, Xiang Mei wrote:
> might_sleep could be trigger in the atomic context in qfq_delete_class.
> 
> qfq_destroy_class was moved into atomic context locked
> by sch_tree_lock to avoid a race condition bug on
> qfq_aggregate. However, might_sleep could be triggered by
> qfq_destroy_class, which introduced sleeping in atomic context (path:
> qfq_destroy_class->qdisc_put->__qdisc_destroy->lockdep_unregister_key
> ->might_sleep).
> 
> Considering the race is on the qfq_aggregate objects, keeping
> qfq_rm_from_agg in the lock but moving the left part out can solve
> this issue.
> 
> Fixes: 5e28d5a3f774 ("net/sched: sch_qfq: Fix race condition on qfq_aggregate")
> Reported-by: Dan Carpenter <dan.carpenter@...aro.org>
> Signed-off-by: Xiang Mei <xmei5@....edu>
> Link: https://patch.msgid.link/4a04e0cc-a64b-44e7-9213-2880ed641d77@sabinyo.mountain
> ---
> v1: Avoid might_sleep in atomic context

No need for this line on the first version of a patch.  It's just to
track changes between versions.

Anyway, looks good.  Thanks!

Reviewed-by: Dan Carpenter <dan.carpenter@...aro.org>

regards,
dan carpenter