From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr2-f2.google.com (mail-wr2-f2.google.com [74.125.225.66]) (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 0E412239E7E for ; Mon, 3 Aug 2026 01:28:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.225.66 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785720516; cv=none; b=uTUPKoE9AevhWU1K4BRDg2FPJTdJYT1r88xpusUD5v/yqp+nZcXBo6fMSmgl2Luif9upRTwqGXn4RqTOF4MD9CXsnRAJdZUEA2iDqbu4aTPtJ+ODilpvuuWwxDhcEp+xzHGbdpKjpV0zLmaQkznDg/vuz+5NakeashcijILKquM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785720516; c=relaxed/simple; bh=6i04O5CFp/4Pk+aYqAnASRf6c3l8QPpoW7WB5FRTflw=; h=Mime-Version:Content-Type:Date:Message-Id:From:To:Cc:Subject: References:In-Reply-To; b=OGpbhu1ULJtwxkHqisj7o7ZehiUqWKm4oERFke60LCsAYWI3NkPd4Hbhzn2jDMoDo8rWVJ12uoJnYopXadZKTETSyAOHg8BjXA1ahpPdPdcCDGaD31Eg8PZkr053SRe+gwre+6Hc3OiZGRDA/wV3S+Z/NUR0Qp49WctZAVgXICw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=PbYQVkKf; arc=none smtp.client-ip=74.125.225.66 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="PbYQVkKf" Received: by mail-wr2-f2.google.com with SMTP id ffacd0b85a97d-4730b8edae6so987799f8f.0 for ; Sun, 02 Aug 2026 18:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785720512; x=1786325312; darn=vger.kernel.org; h=in-reply-to:references:subject:cc:to:from:message-id:date :content-type:content-transfer-encoding:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=y8r93oSZtoqKQ7VM9cC5jOx8tm9JrVZHlrCpEvzQrkw=; b=PbYQVkKfxfIgbU0YxQNBsVuddq1X0GeAF/weZm5/1esRrJwY3Go71zc1uoRj7Lb1DB mg+WIu2xyEnA0hs8N+lRKbIbA/XCKalROEZltAFLjQW0V0GKg0luf2V6gB1U+r7ThbB4 vGFMLrbEC95F3gf6MTZOz0TYev855yuLqI9PHHlbgdVn6NIfLyoDeBkl0/YEYUoThFau I4Toa0SzzsTRmOZSAuWpuPBG0pPF+DHyPsV1pkOcVI2EbMvZWtAaih0KpBOoM7AHWlZM jy6XwBMehtCChIwA8yFsLqlZef2RBe2DcW04ZHA5ZzkmpLpBjXWSlbuqRBwe543NHJjr /VnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785720512; x=1786325312; h=in-reply-to:references:subject:cc:to:from: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=y8r93oSZtoqKQ7VM9cC5jOx8tm9JrVZHlrCpEvzQrkw=; b=mP6QgLMVWxLwQ77flwMwu7GEm1BEKuQenNFVvnYa4oA/DyCKWrX0GS9y6yoLH22st7 xqY2GYdJV20El1+GYlRFeVRKDvUWwImFxoDMunSfOxFHtPTqJRVFEtJdL7YRucYRzZ+F sB041tRuiyUXxEZfUAidVQqlI7tJ18jE17dkRDkdiTpltS7aIPjQVkCMVn5Fbm06C4TX PizIt2HqPrgfG8xuVRCdeTZBcv7o8a3Sojqdj/q3G2Fg1VIXzH6bHTionujwTc5vO/5Q b7e+6KNxkLICB/a0fLkmCT2XNrFrcHIirzH9Qcol4/ZECc/Egzcr2vCqi079boSeZdo+ i1mw== X-Forwarded-Encrypted: i=1; AHgh+RqfzCkf8zv5eKLNbuFA3KxuV7AjyG3Zt8HgRQ9CXg8Js+X0LIbkPFd+pOjcG6dHQ2gCxxYTdLXNGvm1EPM=@vger.kernel.org X-Gm-Message-State: AOJu0Yx34ZBQzUb0aZ93wKa50qDxQqGvLDZGYTk5rUQ0M5Zxxg6jaA5N EM83VPC2BszjWKBjyei1Zm1onqcfzYi4vdHRCbQ1oiy8u1MSyRYqLakO X-Gm-Gg: AR+sD10DXdV3pDYOytUA6aWHSmQXb/sDoSh+BeigzjD0ZxicEPR9c1FsEsWOy0fTXtY 81pAe2SuHzpls2kZ6hT3V2pNEEZbkSURUC2ShjdrYdzMmni9d9SM2rLuht+ilKxwlxQXOA3NsZK RoJDIBwlse+h4HGTYPe4VewvmXGFvxqEPKnHwBuzQG7kUybzmD3XQDad/s5bNYlj1tW4XLvCuWt liTGu5dH3/QTQH0zbdpg7z5FQmc8rQxwDsHuIyny/dDxzrrUchaOm9xefviOcUBPGX4nHnHzwpo Q3y10vXNp+scu8m8h4cvV1BMDckCreSr+NvxjiqvC7ktCE2c8bHCNzsr+vbHE9UYvAY6AMkqjX7 B5I0MacXGOvkxtdnBb/v0iXI/XLKZcwB5idAoUheq0k5oM0Tv98mp+TJDRWiAQbbTzMzaD+oKZ4 QABQHmS0xG50bZ/ZMZ3qp+c8VUXFBbHJDx/3rp9cPperipCN6FJhGPbkOBv0FJL49OMVcTIZkk9 NfA3zT+RCt/PjKJOXf7QMrtc/a6O/xPR1dHkUznvX3M/maIf5/a4sGTRvKjqYIaHOhJ4Lrqc7rM lkxSOV0u/O+f3su6HxU847iEt1xl X-Received: by 2002:a05:600c:4444:b0:493:f6f0:d66b with SMTP id 5b1f17b1804b1-4980c6458aamr155528905e9.1.1785720512186; Sun, 02 Aug 2026 18:28:32 -0700 (PDT) Received: from localhost (nat-icclus-192-26-29-3.epfl.ch. [192.26.29.3]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49808199a68sm127648395e9.4.2026.08.02.18.28.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 02 Aug 2026 18:28:31 -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: Mon, 03 Aug 2026 03:28:30 +0200 Message-Id: From: "Kumar Kartikeya Dwivedi" To: "Jiayuan Chen" , Cc: "Alexei Starovoitov" , "Daniel Borkmann" , "Andrii Nakryiko" , "Eduard Zingerman" , "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 X-Mailer: aerc 0.21.0 References: <20260728060517.95183-1-jiayuan.chen@linux.dev> In-Reply-To: On Mon Aug 3, 2026 at 3:21 AM CEST, Kumar Kartikeya Dwivedi wrote: > On Tue Jul 28, 2026 at 8:05 AM CEST, 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 deadloc= k >> 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 >> >> --- >> target to bpf-next since I think it is moderate. >> --- > > This looks ok to me, but after staring at this function for longer, I thi= nk all > kinds of non-recoverable errors should be using VM_FAULT_SIGBUS vs SIGSEG= V. > > The only case with SIGSEGV should be the flag based request to disable > allocation on lazy faults. That should include the scratch page case, sin= ce it > represents a hole. > > SIGSEGV: BPF_F_SEGV_ON_FAULT, scratch page. > SIGBUS: lock acquisition failure, range-tree failures, page allocation fa= ilure, > kernel PTE install failure. > > All of these SIGBUS are almost improbable, but I think it would be cleane= r to > keep semantics clear. > > Could you follow up with this change? I applied this one for now. > For the scratch page case, I think we do SIGSEGV when the BPF_F_SEGV_ON_FAU= LT flag is set, but SIGBUS otherwise there too, since we could but choose not = to lazy allocate a page due to the program's error / bug.