All of lore.kernel.org
 help / color / mirror / Atom feed
From: Justin Suess <utilityemal77@gmail.com>
To: Xu Yunxiang <xyx2021@mail.ustc.edu.cn>
Cc: bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
	 andrii@kernel.org, eddyz87@gmail.com, memxor@gmail.com,
	ameryhung@gmail.com,  yonghong.song@linux.dev,
	puranjay@kernel.org
Subject: Re: [PATCH bpf-next v7 0/2] bpf: Track borrowed iterator result lifetimes
Date: Fri, 23 Oct 2026 11:43:54 -0400	[thread overview]
Message-ID: <att73Z9XpompG3k1@zenbox> (raw)
In-Reply-To: <20261021210754.3270023-1-xyx2021@mail.ustc.edu.cn>

On Thu, Oct 22, 2026 at 05:07:52AM +0800, Xu Yunxiang wrote:
> Make non-RCU, non-acquired struct iterator results borrow the current
> element lifetime by default. KF_ITER_RET_INDEPENDENT marks the explicit
> exception for results whose lifetime is independent of the iterator.
> 
> Trusted field loads and dynptr constructors propagate the source lifetime
> so derived pointers stay in the invalidation graph. Next preserves the
> iterator itself and invalidates old dependents before both return
> outcomes; destroy propagates outstanding-child errors.
> 
> As Alexei pointed out, the trusted-field rule is generic. Patch 1 now
> explains why an inode pointer loaded from an acquired file becomes
> invalid when that file reference is released, and how the same rule
> applies to fields derived from an iterator result. Patch 2 adds VFS
> tests for the valid before-release access and the rejected after-release
> access alongside the existing iterator lifetime tests.
> 
> The field-propagation overlap with Kumar's related work remains. This
> series introduces no general kfunc borrowed-return annotation; the
> separate bpf_real_data_inode() return-lifetime gap remains outside its
> scope. The iterator policy has no dependency on that annotation.
> 
> Changes in v7:
>   - Explain the generic trusted-field lifetime rule and the file/inode
>     example in patch 1's commit log, as requested by Alexei.
>   - Add a positive and negative VFS test for that example in patch 2.
>   - Rebase onto bpf-next b116ac6087541. The implementation's added and
>     removed lines are unchanged from posted v6; the field-load hunk's
>     context now includes the upstream __nullable handling.
> 
> v6:
> https://lore.kernel.org/r/20260927120406.1041915-1-xyx2021@mail.ustc.edu.cn
> Alexei's v6 review:
> https://lore.kernel.org/r/DMA2SZ5PRG4N.3I51MHSTWUUTS@gmail.com
> Kumar's related work:
> https://lore.kernel.org/r/DLGYPZAL708V.3GFLANAPH2L8O@gmail.com
>
It seems like my patcheset [1] is partially duplicitive of this work.
My fault. I think I got confused by patch 1 subject and only thought it
was an iterator fix.

Seeing as you are further along, I'll yield to you for the iterator
lifetime fixes and the trusted field lifetime fixes :) (everything in
this set)

I'll continue my series and focus on the __derives_ret suggested by
Kumar and the RCU trusted pointer fixes / "Don't apply the trusted
field lists to an RCU-protected parent" suggestion by Alexei instead.
Plus selftests.

Just sending this to deconflict.

Thanks,
Justin

[1] https://lore.kernel.org/bpf/20261020145059.2146170-1-utilityemal77@gmail.com/
> Validation on this candidate with a matching bpf_testmod:
>   - W=1 verifier, full kernel and modules builds passed.
>   - Changed BPF objects and required fixture compiled strictly.
>   - iters: 1/122 passed; 0 skipped.
>   - dynptr: 2/137 passed; 0 skipped.
>   - file_reader: 1/10 passed; 0 skipped.
>   - verifier_vfs_accept: 1/7 passed; 0 skipped.
>   - verifier_vfs_reject: 1/13 passed; 0 skipped.
>   - kmem_cache_iter: 1/3 passed; 0 skipped.
>   - dmabuf_iter: 1/4 passed; 0 skipped.
> 
> The new before-release VFS program loaded on both the unmodified
> baseline and this candidate. The after-release program loaded on the
> baseline and was rejected by this candidate with the expected scalar
> access diagnostic. These annotated programs are load-only.
> 
> The VMs used panic_on_warn and panic_on_oops. No WARN_ON report,
> Oops or panic was found. Unprivileged BPF was enabled only in the
> isolated guests.
> 
> The broad test_progs build used BPF_STRICT_BUILD=0; no compile skips
> were reported. The unfiltered full
> suite, sanitizer and architecture matrices were not run. The fresh
> baseline comparison covers the new VFS example.
> 
> Please queue the verifier fix for stable after it reaches the BPF tree.
> 
> Xu Yunxiang (2):
>   bpf: Track borrowed iterator results by default
>   selftests/bpf: Test borrowed iterator result lifetimes
> 
>  Documentation/bpf/bpf_iterators.rst           |  10 +
>  include/linux/btf.h                           |   1 +
>  kernel/bpf/btf.c                              |  13 +-
>  kernel/bpf/verifier.c                         | 103 ++++-
>  .../selftests/bpf/progs/iters_testmod.c       | 370 ++++++++++++++++++
>  .../selftests/bpf/progs/verifier_vfs_accept.c |  17 +
>  .../selftests/bpf/progs/verifier_vfs_reject.c |  19 +
>  .../selftests/bpf/test_kmods/bpf_testmod.c    |  25 ++
>  .../selftests/bpf/test_kmods/bpf_testmod.h    |   4 +
>  .../bpf/test_kmods/bpf_testmod_kfunc.h        |   5 +
>  10 files changed, 548 insertions(+), 19 deletions(-)
> 
> 
> base-commit: b116ac6087541d3d98031e786adbe9c733cd6df3
> -- 
> 2.43.0
> 

      parent reply	other threads:[~2026-10-23 15:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-21 21:07 [PATCH bpf-next v7 0/2] bpf: Track borrowed iterator result lifetimes Xu Yunxiang
2026-10-21 21:07 ` [PATCH bpf-next v7 1/2] bpf: Track borrowed iterator results by default Xu Yunxiang
2026-10-21 21:29   ` Amery Hung
2026-10-22  3:42   ` Alexei Starovoitov
2026-10-21 21:07 ` [PATCH bpf-next v7 2/2] selftests/bpf: Test borrowed iterator result lifetimes Xu Yunxiang
2026-10-21 21:31   ` Amery Hung
2026-10-23 15:43 ` Justin Suess [this message]

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=att73Z9XpompG3k1@zenbox \
    --to=utilityemal77@gmail.com \
    --cc=ameryhung@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=memxor@gmail.com \
    --cc=puranjay@kernel.org \
    --cc=xyx2021@mail.ustc.edu.cn \
    --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.