From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr2-f0.google.com (mail-wr2-f0.google.com [74.125.225.64]) (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 1CD5F2E7386 for ; Mon, 3 Aug 2026 01:21:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.225.64 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785720106; cv=none; b=XQqk300PiAakg2N4LIGo9xTmMl5TOj15t3lPmZglBq78B5V6qCBZHp29ZMv3shxWc3RC4hkpnQX/ahgHQtb1wQBhdYy4ftNxZIbtmtgOxcbUlvOD2IdjbLZOCWYOAT4TSkj0TVviNU6MpexTd2uykeDA1ZLHi4o4H0Hml1HfjPE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785720106; c=relaxed/simple; bh=VNo+XMcqYzfsyjDQpadV1uocU4uj3LbEOTQZgrPg09k=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=vDdUWH6wmjiKB/xawF/RY3uVO2jrcJKYbaARWjLN2VvlkqzzPkI+xjNt94tLxpFJZNbCJvMZ/r/IGO9PIh9UKOZIzUZuk5owcuPKFIugOgAkkqUHlsfYmlGxQztSQcjmuCj/f/8CdVxbzXRuHB3G6T1So6MM+UOZFaf7zf1EXnA= 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=J84zgguP; arc=none smtp.client-ip=74.125.225.64 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="J84zgguP" Received: by mail-wr2-f0.google.com with SMTP id ffacd0b85a97d-47825ef4012so1540710f8f.1 for ; Sun, 02 Aug 2026 18:21:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785720103; x=1786324903; 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=QdqRShD9VZDhrLxatfTV4kRkPg0UGmMhyIWhN5tmL0Q=; b=J84zgguPM+jh9G5qGMLdcWYD+21oS3l/zqGhGQVBlDcbGseNTkuuZMDaz/fSJ2CxEp M3qEcVWSr2vMejIeUvAEueursy6kV30kKaOCwxr/8tVwsfLZvvfy/uAjTlI+8YhnLTIb NC9Hzwh43W39/c38rw3Md2IVzq41JidLE7/3iiaLH4R/iPxasISOyX++GVDV0/jzHHKD cXYrDLGR2uSgd2BqeXVo3/yDsUoS4W8KS0qhX7H58AG7WSFLJ1+frwEJdLjtQqx3xGA6 uEJGgM7wXYLfWFa+/hsKgFQrLgb76fnZCWuOo44UxEW7heOR6sWj9TE3l8HIEGfZm78b +R/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785720103; x=1786324903; 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=QdqRShD9VZDhrLxatfTV4kRkPg0UGmMhyIWhN5tmL0Q=; b=r3DkMf1N21g1QIcj293iPnxqQqOF6hnjTz5i76Z3sjJptUcUjkKnjyY5wzHOeRqcxD S0ELKqL1gT8W++MV1Wiy/BcgiC7Vb8HayhbAYN04QswFdaLcf0on8Q7RvGK8cKWuvteL CBdPM+hF+5s9sNkJTkOTrmKSIxTgGxwpzM8dTErmgXLe4Nt8zc7A617sXFHo7LsAa9ef nDPl1N0P5SQm8suJSyE3rfPOfiuN2/46yDX9Cvsn0QorGMIDux7TbNrIzI8M5IpyEMuR AQ+48rjntOhl5XAO3lvZJhZKDjxMGEC01JWr/GkTuRx4jhV09k7+BnJTHZ6jXWA+KGhW uvFA== X-Forwarded-Encrypted: i=1; AHgh+RqOeQqTk95DFgs9jUz3RSDaorVH1TeFoG6crdHZbsuX1v+AU4HML9AYmHqdTFW29xSXvK7miCW0gZ89zCs=@vger.kernel.org X-Gm-Message-State: AOJu0YwzPzCTp+9JvSWGh969LAui80QOHNO6XWFUHjPkcZxjsN2SsaZb HuxyPlerKlclpC6SPaqmO4Ttqo7AoAJW9vgBg4ll7oXf5OLhEf68ljV8 X-Gm-Gg: AR+sD10M8I+13Rp9c4zqs65cXddJjMURVRDfXLL1eaoJleBF3Es0QJeYUQmZsbFFxX6 ZB436Rd9RAhfLnOnFi9TaK9Z6byyu5qtHElYyA7VUgW++oDMpqNJi12RNOTD3+OeEldy0/v+NEd A15vzrY09FwWM9SsKJzOC1uri0Qxbw0UEZYiaah7L/p/PN0VEQOGJTzDvG+tkmiFt6Am52hxXy5 cbhGFq7REZRhSf4jgHXbT7UGmBdqBntSgX6HlQa7rn5/g7O3Hj053OUuAV6yFzDVvEovklNtuzx jAaHi4/o+tfWmBaNGG1qjDhwQl/YqN2h6WUktWEdrNn5H92RScbxe79odckAG8rQ+TViKj6GvPL z/JwsiPs6VqhWIlVt5UwrqpqYIGDp4tCvqJK1+XUJImI6ZvDzTkjiPxwWMSi1STI8miOXcOkboI 751uD6IDP/DMaJNRnIrBNqLGrIGXL/3Bx8XvXiQUCOjfMNVGpHOEv5VoLG5qV6xm6YvOEb4IjzP KIPPk6NPJKUdTUJFieeBx6yc4b4LYSg0IzmYq/ShTRgYHM3b0jrX0E+Oj8AN2uJUiLmhhEza2gD rTBDuTWVm0/9gO/pw8B1XMnM3Zfe6xp88xipkQ== X-Received: by 2002:a05:6000:25f3:b0:46e:1815:6a83 with SMTP id ffacd0b85a97d-47fd72f1666mr20060691f8f.29.1785720103309; Sun, 02 Aug 2026 18:21:43 -0700 (PDT) Received: from localhost (nat-icclus-192-26-29-3.epfl.ch. [192.26.29.3]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47fd458adc9sm29487799f8f.27.2026.08.02.18.21.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 02 Aug 2026 18:21:40 -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:21:39 +0200 Message-Id: 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 From: "Kumar Kartikeya Dwivedi" To: "Jiayuan Chen" , X-Mailer: aerc 0.21.0 References: <20260728060517.95183-1-jiayuan.chen@linux.dev> In-Reply-To: <20260728060517.95183-1-jiayuan.chen@linux.dev> 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 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 > > --- > target to bpf-next since I think it is moderate. > --- This looks ok to me, but after staring at this function for longer, I think= all kinds of non-recoverable errors should be using VM_FAULT_SIGBUS vs SIGSEGV. The only case with SIGSEGV should be the flag based request to disable allocation on lazy faults. That should include the scratch page case, since= it represents a hole. SIGSEGV: BPF_F_SEGV_ON_FAULT, scratch page. SIGBUS: lock acquisition failure, range-tree failures, page allocation fail= ure, kernel PTE install failure. All of these SIGBUS are almost improbable, but I think it would be cleaner = to keep semantics clear. Could you follow up with this change? I applied this one for now. > 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); > > 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; > > page =3D vmalloc_to_page((void *)kaddr); > if (page) {