From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) (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 CE52E348C64 for ; Thu, 28 May 2026 21:30:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780003833; cv=none; b=KckK9YBHmRdWp1s8UsUIcLIrCOWfjCT7N8w8v2sq4oyWyr129/ne7gPUMqYN01WJzVjbS7945KdtFBjOuIYP7PJsrZVS+ALc1lW3Z4X3on1Y9bDyyuVXYJZDvnyiWWIFsi76qexX+H40Si+HJSBiRnJPYY2T3bg0b+J42h3x+/c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780003833; c=relaxed/simple; bh=Z5fwT8m/j0scgq8nZY7qsq1dvsdBoBnzZKP0fDmds4s=; h=Mime-Version:Content-Type:Date:Message-Id:From:To:Cc:Subject: References:In-Reply-To; b=Gtc91lxf1MVQNgEnHOgwlNkJAQbdjqvuHsoq/x08i+awwLgKl9OUf9KiOvXzybS+MVA87RGyOs8fY1FHWvlKp3c2tAHjxUEijT/bpR4CL3SA4cgJ9R2IBNFbaicW1Q0VJXSKPtKCBHIl/Rv1qml+omq2Y6q3obyJJeBrb8bieKA= 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=Wu0ZIIUc; arc=none smtp.client-ip=209.85.210.41 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="Wu0ZIIUc" Received: by mail-ot1-f41.google.com with SMTP id 46e09a7af769-7e6128bd9b3so3486319a34.1 for ; Thu, 28 May 2026 14:30:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780003831; x=1780608631; darn=vger.kernel.org; h=in-reply-to:references:subject:cc:to:from:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=wpHrgIeXXcvDfmuKsXXjHhEfFrUsBGF9Cp2mPrCFg1E=; b=Wu0ZIIUc85en9tHUNmjt+lK/rxEPFaY8RvLYvA+1ZLX3L4EWBnAHHPawcR3bVi0t4E 29l/4r953NkIMku5rjt5WtRTL1A5J9NeXsmGnytqTETg5alvRo04noF/szbznPvzgKht PgbpKvqwK97OSKre8gBQC0QVqhGgo3qlqyRLIN+iwc8vijBXj+1rQbCc/0IM+CgFX0Ra pLbrx6EN6ZIqr7GU1xpiA9gqAoUyGqrGBVHGfA3gJ8OzKxR3UEefpYpx+p8N0YXnt0Xt uXH3O5j5bY8kNSk4PRsW4uXbAkGfL6CwFQFFJPOgTcTfVcQEqeMGWJzdJq2HGl3iL3an R+MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780003831; x=1780608631; h=in-reply-to:references:subject:cc:to:from:message-id:date :content-transfer-encoding:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=wpHrgIeXXcvDfmuKsXXjHhEfFrUsBGF9Cp2mPrCFg1E=; b=IVib2h1VCp5QyuI/vzMW1WiXuW36t3ldq2ID61tLmo8l01H+1n+WRb6kvRbeCazH9P AHtypQ0lNEfYY/XBKK46/0cEo+zhRbTICY/jXX5/JYjQlOvMHSXAuk6p7w5d/dzOLR+f BYgSMK6nRrwKgmozNbiDY5foombUS3n1NHDa23t1FjvBdcRhdyetWrHC85QO1kl+Kx4C Q2Tx2zJAKpp9RApzAYIxL3s+EA0KRS9rpQhUsp8YlwwXybYVn8oA/mTDCZfnNruZQs0i ayUNmPqzzXZlbvBkeTtuK8yTPIrWOWoJiz04rE8wg6BIVvVMhyZKU+suY5BQUcHJ8Gkh 2c5w== X-Forwarded-Encrypted: i=1; AFNElJ9J7Djx4FhPp6/qAu3xJOO+FhG+g4WUHDWBYcx6bRmqj+dcg4jGNFKMn5+RcdFbgbuq69lkE0Jc6rgJ9pU=@vger.kernel.org X-Gm-Message-State: AOJu0YyxFk7SkXCAquF4xmb+Uuum6F9rhcHSm87SFfLKFW+xmjzav4eV DHw9aTn3DeHSFG5GFh7C9qXpGITw0e6I2q6PBJTCODNaPw/4u0vUzj5i X-Gm-Gg: Acq92OFOTnOjeCJrb0cGSHftISWdhW1QkXQipha6EswY/hY8vC7W8ffgy++p7X0jZbY hyTohlczXG4xEkevTza86bBEtUgk/uveteelQTQmJp1eC9OVmRE1H/gxBBJyzDrE3G7x+u+q8sv VLX9f/7N7/mksJiGLQvBZ3bp+qKioaws9jMXpWmuZZnrhRdyQ1odztBbjB1gakN4G+JKlR1nTaL Cm2PcVttV+s0PxjxOoxNLZVFdsjjq7+gsr1vqrpsunP34T+MurzvPT21nT+ZYaFlyEOPXeExbtq w1ixZ8JYDweKjASepB46FFansrBNkuIikqIMykQGBbdFoawzks3eb1Qr9+EuAIKpHpZyg1dhKvJ E+uycmmjz0wsDzFgogxj9pKA1vdrGKcbQw2L3F307ueRzJkLt/gDdKXMU6zUt19/IUgDGCAUSX7 GSwaMq8ViJjVsdkXI0MwgoRTTgXaMnTji4N0jMji73zTHRYEaNXYkjKAvngftxTLwxHC1R9TeOe 38HxmQZXpZHwCpKOsIpFcLiCbuw X-Received: by 2002:a05:6830:81e9:b0:7d7:570b:6800 with SMTP id 46e09a7af769-7e694e30aa5mr218271a34.23.1780003830565; Thu, 28 May 2026 14:30:30 -0700 (PDT) Received: from localhost ([2a03:2880:10ff:47::]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7e695212f9asm129362a34.13.2026.05.28.14.30.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 28 May 2026 14:30:30 -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: Thu, 28 May 2026 14:30:28 -0700 Message-Id: From: "Alexei Starovoitov" To: "David Hildenbrand (Arm)" , "Tejun Heo" , "David Vernet" , "Andrea Righi" , "Changwoo Min" , "Alexei Starovoitov" , "Andrii Nakryiko" , "Daniel Borkmann" , "Martin KaFai Lau" , "Kumar Kartikeya Dwivedi" Cc: "Peter Zijlstra" , "Catalin Marinas" , "Will Deacon" , "Thomas Gleixner" , "Ingo Molnar" , "Borislav Petkov" , "Dave Hansen" , "Andrew Morton" , "Mike Rapoport" , "Emil Tsalapatis" , , , , , , Subject: Re: [PATCH 2/8] bpf: Recover arena kernel faults with scratch page X-Mailer: aerc References: <20260522172219.1423324-1-tj@kernel.org> <20260522172219.1423324-3-tj@kernel.org> <7fd673df-22f3-4d70-a779-ea0b878188b3@kernel.org> In-Reply-To: <7fd673df-22f3-4d70-a779-ea0b878188b3@kernel.org> On Tue May 26, 2026 at 5:45 AM PDT, David Hildenbrand (Arm) wrote: > > There is still the chance that apply_range_set_cb() could race with scrat= ch > insertion, right? yes, it can race, but the fix is to remove only: - /* sanity check */ - if (unlikely(!pte_none(ptep_get(pte)))) - return -EBUSY; It was sanity check, now it's simply in the way. It should do set_pte_at() unconditionally. It's totally fine to set it to proper page instead of scratch or empty. Tejun, do you mind sending a patch to remove these 3 lines or should I do it? Changing topic. re: zap_vma_range() issue. It's not forgotten, just complicated, since we can't just take mmap_read_lock under arena->lock, since arena_vm_close()=20 is called with mmap_write_lock held and it takes arena->lock. Will figure something out. > Shouldn't we also be using ptep_try_set() there? > > The nasty thing is handling whether ptep_try_set() actually works. > > Something like the following on top, maybe? > > > diff --git a/kernel/bpf/arena.c b/kernel/bpf/arena.c > index 49a8f7b1beef5..086bea3f3698e 100644 > --- a/kernel/bpf/arena.c > +++ b/kernel/bpf/arena.c > @@ -122,19 +122,27 @@ static int apply_range_set_cb(pte_t *pte, unsigned = long > addr, void *data) > { > struct apply_range_data *d =3D data; > struct page *page; > + pte_t pteval; > > if (!data) > return 0; > - /* sanity check */ > - if (unlikely(!pte_none(ptep_get(pte)))) > - return -EBUSY; > > page =3D d->pages[d->i]; > /* paranoia, similar to vmap_pages_pte_range() */ > if (WARN_ON_ONCE(!pfn_valid(page_to_pfn(page)))) > return -EINVAL; > > - set_pte_at(&init_mm, addr, pte, mk_pte(page, PAGE_KERNEL)); > + pteval =3D mk_pte(page, PAGE_KERNEL); > +#ifdef ptep_try_set > + if (unlikely(!ptep_try_set(pte, pteval))) > + return -EBUSY; > +#else > + if (unlikely(!pte_none(ptep_get(pte)))) > + return -EBUSY; > + > + set_pte_at(&init_mm, addr, pte, pteval); > +#endif > d->i++; > return 0; > }