Re: [PATCH] mm: vmalloc: annotate find_vmap_area_exceed_addr_lock() for lockdep

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Mar 27, 2024 at 11:21:59AM -0600, Jens Axboe wrote:
> On 3/27/24 11:04 AM, Uladzislau Rezki wrote:
> > Hello, Jens, Omar!
> > 
> >> On Tue, Mar 26, 2024 at 04:24:01PM -0600, Jens Axboe wrote:
> >>> On 3/26/24 3:25 PM, Jens Axboe wrote:
> >>>> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> >>>> index 22aa63f4ef63..26a69fa6809c 100644
> >>>> --- a/mm/vmalloc.c
> >>>> +++ b/mm/vmalloc.c
> >>>> @@ -1032,7 +1032,7 @@ find_vmap_area_exceed_addr_lock(unsigned long addr, struct vmap_area **va)
> >>>>  	for (i = 0; i < nr_vmap_nodes; i++) {
> >>>>  		vn = &vmap_nodes[i];
> >>>>  
> >>>> -		spin_lock(&vn->busy.lock);
> >>>> +		spin_lock_nested(&vn->busy.lock, i);
> >>>>  		va_lowest = __find_vmap_area_exceed_addr(addr, &vn->busy.root);
> >>>>  		if (va_lowest) {
> >>>>  			if (!va_node || va_lowest->va_start < (*va)->va_start) {
> >>>
> >>> Omar said he tested this and ran into lockdep complaining as it only
> >>> supports 8 subclasses. So this patch can't work, but that still leaves
> >>> the current kernel code buggy...
> >>> 	
> >> It is a bit tricky. Let me rewrite it so a lockdep does not complain.
> >>
> >> Thank you for your report.
> >>
> > 
> > Could you please check and test below? It is based on latest 6.9-rc1 tip.
> > I have reworked it a bit and now it does not hold two locks so the lockdep
> > should not complain.
> 
> Works for me:
> 
> Tested-by: Jens Axboe <axboe@xxxxxxxxx>
> 
Thanks!

I will add tags and send out the patch.

--
Uladzislau Rezki




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux