Re: [PATCH v2] kasan: remove kasan_find_vm_area() to prevent possible deadlock

[Byungchul Park <byungchul@sk.com>]

On Sat, Jul 12, 2025 at 03:46:10PM +0000, Yeo Reum Yun wrote:
> Hi ByungChul,
> 
> [...]
> > I checked the critical section by &vn->busy.lock in find_vm_area().  The
> > time complextity looks O(log N).  I don't think an irq disabled section
> > of O(log N) is harmful.  I still think using
> > spin_lock_irqsave(&vn->busy.lock) can resolve this issue with no worry
> > of significant irq delay.  Am I missing something?
> 
> I don't agree for this.
> since in PREEMPT_RT case, it has the same problem.
> 
> In case of PREEMPT_RT, spin_lock_irqsave() becomes rt_spin_lock() which is sleepable.
> But, KASAN calls "rt_spin_lock()" holding raw_spin_lock_irqsave() which is definitely wrong.

It's another issue than irq handling latency, but it's about lock usage
correctness.  You are right.

	Byungchul

> But as Uladzislau said, without reference count manage, UAF can always happen.
> IOW, If KASAN to dump vm information, I think we need:
>     1. manage reference for vmap_area.
>     2. find_vm_area() with rcu version.
> 
> 
> Thanks.
> 
> --
> Sincerely,
> Yeoreum Yun