From: Tejun Heo <tj@kernel.org>
To: bot+bpf-ci@kernel.org, Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Alexei Starovoitov <ast@kernel.org>
Cc: david@kernel.org, arighi@nvidia.com, memxor@gmail.com,
akpm@linux-foundation.org, rppt@kernel.org, andrii@kernel.org,
daniel@iogearbox.net, martin.lau@linux.dev,
martin.lau@kernel.org, eddyz87@gmail.com,
yonghong.song@linux.dev, emil@etsalapatis.com,
void@manifault.com, changwoo@igalia.com, clm@meta.com,
ihor.solodrai@linux.dev, linux-arm-kernel@lists.infradead.org,
linux-mm@kvack.org, bpf@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf-next] arm64: mm: Complete the PTE store in ptep_try_set()
Date: Sun, 07 Jun 2026 10:04:19 -1000 [thread overview]
Message-ID: <1780862659.ccb18e27e916dc4b@kernel.org> (raw)
In-Reply-To: <5f68f44310d4878185fd5ebc52d66530b99f174c6d04ab1170dc53cefaa54568@mail.kernel.org>
> Can this path actually loop, or is the deferred barrier guaranteed to be
> flushed before the faulting instruction is retried?
I don't know the arm64 paths well enough to say. What I can see is that
ptep_try_set() only runs as an apply_to_page_range() callback, and
apply_to_pte_range() brackets it with lazy_mmu_mode_enable()/disable(), with
the disable() flushing TIF_LAZY_MMU_PENDING before returning. The barriers
would land before the access is retried. It also looks like the same
queue_pte_barriers() path __set_pte() already uses. I'd defer to Catalin and
the arm64 folks on whether that actually closes the case.
Thanks.
--
tejun
next prev parent reply other threads:[~2026-06-07 20:10 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-01 18:37 [PATCH bpf-next] bpf: Replace scratch PTE atomically when allocating arena pages Tejun Heo
2026-06-01 18:58 ` sashiko-bot
2026-06-01 19:19 ` Tejun Heo
2026-06-01 20:15 ` bot+bpf-ci
2026-06-02 22:09 ` Tejun Heo
2026-06-06 16:06 ` Catalin Marinas
2026-06-07 7:59 ` [PATCH bpf-next] arm64: mm: Complete the PTE store in ptep_try_set() Tejun Heo
2026-06-07 8:12 ` sashiko-bot
2026-06-07 8:38 ` bot+bpf-ci
2026-06-07 20:04 ` Tejun Heo [this message]
2026-06-07 20:31 ` Catalin Marinas
2026-06-08 7:25 ` [PATCH v2 " Tejun Heo
2026-06-08 8:43 ` Catalin Marinas
2026-06-02 22:29 ` [PATCH bpf-next] bpf: Replace scratch PTE atomically when allocating arena pages Kumar Kartikeya Dwivedi
2026-06-05 15:30 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1780862659.ccb18e27e916dc4b@kernel.org \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=andrii@kernel.org \
--cc=arighi@nvidia.com \
--cc=ast@kernel.org \
--cc=bot+bpf-ci@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=catalin.marinas@arm.com \
--cc=changwoo@igalia.com \
--cc=clm@meta.com \
--cc=daniel@iogearbox.net \
--cc=david@kernel.org \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=ihor.solodrai@linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=martin.lau@kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=rppt@kernel.org \
--cc=void@manifault.com \
--cc=will@kernel.org \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.