From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) (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 EE7BF42048D for ; Wed, 29 Jul 2026 21:51:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785361924; cv=none; b=Ie9W7k269lebFkTDGTufzYK3zgaXRJK652ClKTdl+cY7O5yEeXNkKk0mz+1ZSVyB6UvDpOxloTFLVZdFIBqOuMMhtNs4uhVIGB3/cjn33sUdnlKlxjrJKNX7PspXTRgw5VJmrcQwP3XY7EuPpII03n4mohfMsa7jWKxvVd791/g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785361924; c=relaxed/simple; bh=f1sNXUEhd5G+MN0jVhIrIwwozHXwZG5dNEjWm+ZL6jI=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=s1z1DCgbaXcR5oulzsI6R6d0lP9LDgKF3v6YRS6FsKSF/rhBWIS6eNBOxhgStEysk6d0zfDSqBbkTAFAXRD8hcV8wM06P5GZa6ZQpHKbaXWKl1M0a4OL0QBLdRLGSKzS8eJ4uPBj9jTagrhmHdoVU0KMEtK087TwtgEcPVtPmr8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=etsalapatis.com; spf=pass smtp.mailfrom=etsalapatis.com; dkim=pass (2048-bit key) header.d=etsalapatis-com.20251104.gappssmtp.com header.i=@etsalapatis-com.20251104.gappssmtp.com header.b=CF+tN1hX; arc=none smtp.client-ip=209.85.214.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=etsalapatis.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=etsalapatis.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=etsalapatis-com.20251104.gappssmtp.com header.i=@etsalapatis-com.20251104.gappssmtp.com header.b="CF+tN1hX" Received: by mail-pl1-f172.google.com with SMTP id d9443c01a7336-2cf41bab353so25363705ad.0 for ; Wed, 29 Jul 2026 14:51:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=etsalapatis-com.20251104.gappssmtp.com; s=20251104; t=1785361910; x=1785966710; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=AraEorwOHfPmz/tjxiQ5QFMckGEZDI0HCLwYm0eDCS4=; b=CF+tN1hXVmUHvt8EmDE2yaV7gW30aFmDZNJ/90J0oEEFSebqjZRq4/GIsWEktjD+zl aRGwkWAo7LfloiCcslUS8IpkYa0BixTTdEnCkhZtGv2mCwS+MZVS5h5p/XXufyn82/47 MN/xl/Zf7ta7yGQD4H14Va621UiwmINe+kv9yIJYSLxHYxxHoxZUpycsqpfb0ORsFmCI DT8FRZEfY5qxRDu//PVyVQC0mfCGk1E63DvFcVOzUQf12wnpE0Mqtdu9Pqh/jL/yAQJb +YdekgtmWhCSM2XE547Da+9OwoYyFA8tsckV3eLVE5n0MhhNRSG3suOd8O4gh3mv7aTH 1/eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785361910; x=1785966710; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-type:content-transfer-encoding:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=AraEorwOHfPmz/tjxiQ5QFMckGEZDI0HCLwYm0eDCS4=; b=EUxEU7+Cky+ZqSXWbqHmR2M6vgTm+dZb1QC0rD3pCuNBcKCLoKdTYnvnILMRqltJNH j9wGrWMvqqalrrR5MFLhg3KzpECIW336o5olwySyuTJe9/VUQUK9VY+fnBU8DultHYQt OqsxZh1W4jpFGcHqYVe3lqEdJEu/zUs0G7sMPxiiXiQyDdOTsxLWNyjLXfSCGMvjIdVV FqpWViuHLlcjlGsp85LMGIILQgav6v0+w3mCEqAur45XhiwDE/RC6aK7+iMOOMOM2aJS 5/y4LSJcD5rXUeo+yRD+f0xBk/qfecQW5P9PkTCR/mt2/9hGwVv/HfyZKFz6b/lORUZs 6Qgw== X-Forwarded-Encrypted: i=1; AHgh+RppIqWYzFP+rUPlXmz7ZFKPUCYTA5tMVHUZFLSoRMXLBRZ+TJuZfss6mahzpMQTM/1zqF0HVx+z37582y8=@vger.kernel.org X-Gm-Message-State: AOJu0YzjsdYwWSKtQ9Qyf2iu12t8ptlwqw/2jMSBdPDA9X/AXxNzbAwW D6wLq9rew87bT/0Q2SRV62zwNdLSPYQKmqHwKcVK7gg3TuXZBTDvCaGCRASbm6a0p/k= X-Gm-Gg: AR+sD10q6upv6DmNMGdFknaM3HOiylhLrLSX+e/iOfxB3w2PiOJI/XybvonGljr60iR vpMVvOHUzG2mTcL3Ga6M/isuLAsL3bkQPgEaU4QTsCbatVMThN5x+gd5TrVw7Qo6nm/fjMhAWW5 RSH2Q+hs9azTimPm01laGjtiYlEGiFw/VjO6+2tmhT32TGtDsrwIJF8qRJiGgyAszCt/elph7Xi KrksVKkMUpjKGu/DG1JUwUVXr49JcrrXwETl2/6c/R5YYR5lMAERLaCwCG9B32993+Mg08bNI5L gLiOHYs4WhjUWCy/mNvwY00L2QUVzBdhZ4FJB2bLxA/AEO7Eq5wFe7zU1eou6ZhyzHi/8Jcta8E VlP/GCXJtpoogYbLoi4eMEaBWJHUpEC1JM3j6Y3teE6Y0qjuhWU939Y74TWfCPlNIcka+OHlKqO TJGxkI4ppun0TEO+7ppmu1u59OL3CUuAooESiFUBpIWtrB X-Received: by 2002:a17:903:24f:b0:2c9:9a19:df with SMTP id d9443c01a7336-2d035be322emr868825ad.18.1785361910499; Wed, 29 Jul 2026 14:51:50 -0700 (PDT) Received: from localhost ([2620:10d:c090:600::1:d447]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-31504baa01dsm14293935eec.12.2026.07.29.14.51.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Jul 2026 14:51:50 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 29 Jul 2026 17:51:47 -0400 Message-Id: Cc: "Alexei Starovoitov" , "Daniel Borkmann" , "Andrii Nakryiko" , "Eduard Zingerman" , "Kumar Kartikeya Dwivedi" , "Martin KaFai Lau" , "Song Liu" , "Yonghong Song" , "Jiri Olsa" , "Emil Tsalapatis" , "Puranjay Mohan" , Subject: Re: [PATCH bpf-next] bpf: arena: fix mmap_lock deadlock on arena lock failure From: "Emil Tsalapatis" To: "Jiayuan Chen" , X-Mailer: aerc 0.21.0-0-g5549850facc2 References: <20260728060517.95183-1-jiayuan.chen@linux.dev> In-Reply-To: <20260728060517.95183-1-jiayuan.chen@linux.dev> On Tue Jul 28, 2026 at 2:05 AM EDT, Jiayuan Chen wrote: > Reported by the Sashiko AI review. > > arena_vm_fault() returns VM_FAULT_RETRY when it can't take > arena->spinlock, but it never took mmap_lock. The fault path assumes a > VM_FAULT_RETRY handler already dropped mmap_lock and re-takes it on the > retry, so mmap_lock gets taken twice and can deadlock: > > do_user_addr_fault() > { > fault =3D handle_mm_fault(...); // calls arena_vm_fault() > if (fault & VM_FAULT_RETRY) > goto retry; // re-locks mmap_lock > mmap_read_unlock(mm); > } > > Return VM_FAULT_SIGBUS instead, for two reasons: > > 1. We could keep VM_FAULT_RETRY, but then we'd have to drop the fault > lock first and cap the retry ourselves, the way __folio_lock_or_retry(= ) > does. > > 2. A failed raw_res_spin_lock_irqsave() already means a possible deadlock > was detected, so retrying just hits the same lock again. > > So returning VM_FAULT_RETRY here is overkill. > > Fixes: b8467290edab ("bpf: arena: make arena kfuncs any context safe") > Signed-off-by: Jiayuan Chen Reviewed-by: Emil Tsalapatis > > --- > target to bpf-next since I think it is moderate. Agreed, I think either branch is fine. > --- > kernel/bpf/arena.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/kernel/bpf/arena.c b/kernel/bpf/arena.c > index 34f023a537fe..555ee2531ef9 100644 > --- a/kernel/bpf/arena.c > +++ b/kernel/bpf/arena.c > @@ -490,8 +490,12 @@ static vm_fault_t arena_vm_fault(struct vm_fault *vm= f) > kaddr =3D kbase + (u32)(vmf->address); > =20 > if (raw_res_spin_lock_irqsave(&arena->spinlock, flags)) > - /* Make a reasonable effort to address impossible case */ > - return VM_FAULT_RETRY; > + /* > + * A failed lock means a possible deadlock was detected. Don't > + * return VM_FAULT_RETRY: this handler never took mmap_lock, but > + * the fault path would re-take it on retry and deadlock. Fail. > + */ > + return VM_FAULT_SIGBUS; > =20 > page =3D vmalloc_to_page((void *)kaddr); > if (page) {