From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CC3B1374A1E for ; Fri, 12 Jun 2026 17:08:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781284085; cv=none; b=YwJv4swB9gEJWfpTMdAVRH/nshPFqAF2/YUSh7Ef+4eHxYnHIKZPx9ZRykHIvLWS/FTyc5u3y+JchsxSvgCYZMSBGICMhQbwOa4NWvYbKoSUkePfeKHWhEzShskPC47juwFQD1RIuT6z70XVc9/EJ2gnZOEwu33Ft/rhbgxwvfs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781284085; c=relaxed/simple; bh=h83cZuhx86PznVMJOv1LGALcQExDxFPtMSyWm73fAF8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=jH/xjin7Lwc2soaW0gxFYo+khraCmWppF3Ki7W5dSLVWA+NU71f7Uz78wyDWmjMG2klhzkrwNdohwEkilM8qKVVwYJMBuwEAeUqff6Wy1sWoIILCs0DqhKVtiYmA/HFVf7cZwvfHqSxeGGKe22Q2xOerVnBKVN8lkPvKRXZBSIg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=CU7IQkGj; arc=none smtp.client-ip=209.85.214.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="CU7IQkGj" Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-2c0b1a48855so3405ad.0 for ; Fri, 12 Jun 2026 10:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1781284083; x=1781888883; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=HPeZaPzs0udTqN8U0AOdGBgcRR2p1XdQkPuDGe3FfyI=; b=CU7IQkGjJJnqxPl7TVpRGONn95WTHJBnOk9UyeodmgsviVBANzrgc5ElFKfxWAp8Zi y0gy/adziAlDfw9f5wKeBXHvF5sDfxdCYMVMidK4svcMN2V+as9KmWjwg+mWgfAFreUR f7Hq2MrB66iAk7zlCOhahTyrGR4CU2hiWGfuM7o3b7FXvGjFcMpCK8OON9Ub9O+4Fs3o VTK6eYdW0JssHqQF0UrEinryuOLTd3HbRkPBh7d0cm6+WcjZf5c1LEyH/vq8VdAPVmU2 OuaTvO4N0ABFQjGjfRpvlaqP/ciOKXnOteo21FBViRSvWMqksYDqkAb8xM7X6eabekUv FdVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781284083; x=1781888883; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HPeZaPzs0udTqN8U0AOdGBgcRR2p1XdQkPuDGe3FfyI=; b=cvMhfD7iFLPWb4rWQ1FeugVMz4juIjTfHhJ16zScLcUdD321zsCY2AkJr/j/br962k nW/qu2cP6QLEwz2S0VjGIK+NC0ltxUFX2ReYCsHnKXNgeMZI58aAcxu1C+eiOriEaxFL 0o2l1zK1HG9F5wEOnZ0kb7eJWo0FhciPmEop26UhjFM3uMav8Xytxmxl5PvMiFaCF3bA 8ZX30I1YlLy+hX9irqYk1sfBRnFCBHA6jD5e8dC7Kan/BolTqx9Bf7b9kl4SXcMkp/VU 175CnUwAjkhKjdtid/DVcZqaUHDYdLOQZfKIOpRteyvUn2aO4tLfKqaZ71fnjPhQ2ZQd U5Iw== X-Forwarded-Encrypted: i=1; AFNElJ82X3ah1r5a4QcPJEZ/ATmT40VabkTt4BddQqMgsFAyQ4mgbrybr6kiS84wft1mGzmdls4DWQI=@vger.kernel.org X-Gm-Message-State: AOJu0YykudKR72DMNbv6LJNmQKzUyR+bI0cbvtOGl0tXCwbg9Xl+ftNo 5wbGVSadyNb/rNjkYaDQdGP56Qfq1+mH5hAGAakMFtxiv4D09RuQsI6pLLJ1E/gqxA== X-Gm-Gg: Acq92OHyNF4i4PaKwFLzgoUFPCNg6i6eoup1MuZXnUMSMZ2ywsGMzUAFSXcVceUEKWz PXcQXI+xxS0Mt+S0uwHEXz9lYQL7iZ0sMyxqKpLi7UBdHNZXdoM7VQA2ZGfv0koKB4GLTEhCiRF RnKRxYBWKf8LB5ZeAP2+w83x/sfa885aph1M3o+M6AGlrBDC4rEWQDohtPoaZJUVb2uXSIjnJ+j BrtbtYj6ZToN7TxfrBAeCxUoDowcgPNYE3peDxbOMhwnlrvs+WhHwjT1ZmcUt+9zYTs4yu32SfR zqb16WNtc3a33q3F/56kfJiSL9yvevWP9erfRS0xuVlX6PwJFMn8gPikwJ/i1TvfPi6cZykFNFt 0zQexxGV2j5sljbwajoQFZl1XheM08Gb3F7WipAj8+YAvQ5XX7iMB2gya9QzjeXqXf9RJcTdQUx N7vQ4Yc0l4QajC3m4H2oQttEqZuuDxQR37rCg4HizTScoyMt0E6EWVeSYL11BAKFwADuhFNBfNS u/+/o++Kt2ylWLnC05EwJKcOAVmQJ5TIbF/1YAGCjWgWA== X-Received: by 2002:a17:903:4407:b0:2bf:1153:54a0 with SMTP id d9443c01a7336-2c6651871abmr15805ad.23.1781284082627; Fri, 12 Jun 2026 10:08:02 -0700 (PDT) Received: from google.com (112.174.16.34.bc.googleusercontent.com. [34.16.174.112]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2c42fbb5b79sm25331385ad.36.2026.06.12.10.08.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Jun 2026 10:08:01 -0700 (PDT) Date: Fri, 12 Jun 2026 17:07:56 +0000 From: Carlos Llamas To: Dave Hansen Cc: Suren Baghdasaryan , "Vlastimil Babka (SUSE)" , Alice Ryhl , Dave Hansen , linux-kernel@vger.kernel.org, Andrew Morton , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Christian Brauner , David Ahern , "David S. Miller" , Greg Kroah-Hartman , "Liam R. Howlett" , linux-mm@kvack.org, Lorenzo Stoakes , netdev@vger.kernel.org, Shakeel Butt , Todd Kjos Subject: Re: [PATCH v2 2/5] binder: Make shrinker rely solely on per-VMA lock Message-ID: References: <20260610230409.A44D29FA@davehans-spike.ostc.intel.com> <20260610230413.D68967BC@davehans-spike.ostc.intel.com> <131c6a49-9177-418b-a653-8f13942fb8d3@kernel.org> <876077cc-db6a-4517-9d81-cdfbb43e599e@intel.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Jun 12, 2026 at 09:54:58AM -0700, Dave Hansen wrote: > On 6/12/26 09:41, Suren Baghdasaryan wrote: > >> I think the key to distinguishing between: > >> > >> vma==NULL because there's no VMA > >> and > >> vma==NULL because of a trylock failure > >> > >> is binder_alloc_is_mapped(). It won't return false until vm_ops->close() > >> finishes. vm_ops->close() shouldn't be able to happen while > >> lock_vma_under_rcu() is held. So if you've got a non-NULL VMA, you've > >> also got a stable is binder_alloc_is_mapped(). > > By "stable binder_alloc_is_mapped()" do you mean it would always be > > true? > > By stable, I meant that it can't change. > > vma = lock_vma_under_rcu() > mapped = binder_alloc_is_mapped(); > > vma_end_read(vma); > > During it can't go from true=>false or false=>true. > > false=>true never happens from what I can tell. It's just plain > impossible given the current code. > > true=>false is locked out because when lock_vma_under_rcu() is held. > > > Asking because in your patch you removed this condition: > > > > - if (vma && !binder_alloc_is_mapped(alloc)) > > - goto err_invalid_vma; > > > > So, previously if we found the VMA but binder_alloc_is_mapped()==false > > we would bail out and now we don't. Are you reasoning that this > > combination is impossible? > > It's not impossible, but I do think it is irrelevant. Or at least that > the *VMA* is irrelevant in this case. binder_alloc_is_mapped()==false > means that the binder VMA is gone. It's not in the maple tree, and it's > not coming back. If a VMA is found, it's an impostor. > > That's why I did: > > - if (vma) { > + if (mapped) { > > The question isn't whether a VMA was found. The question is whether the > binder VMA is still mapped at page_addr. *That* is best inferred from > binder_alloc_is_mapped(), not the VMA lookup. > > At least that's what I decided after staring at it for far too long. Yes, I _think_ binder_alloc_is_mapped() can help distinguish between the two scenarios (contention vs vma-close). However, I think it would be simpler and safe to do an early exit: diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c index 88c3e1667d5b..9dd7d927249d 100644 --- a/drivers/android/binder_alloc.c +++ b/drivers/android/binder_alloc.c @@ -1149,6 +1149,8 @@ enum lru_status binder_alloc_free_page(struct list_head *item, * for 'page_addr'. */ vma = lock_vma_under_rcu(mm, page_addr); + if (!vma && binder_alloc_is_mapped(alloc)) + goto err_vma_lock_failed; if (!mutex_trylock(&alloc->mutex)) goto err_get_alloc_mutex_failed;