On Wed 11-06-25 11:08:30, Song Liu wrote:
> On Wed, Jun 11, 2025 at 10:50 AM Tingmao Wang <m@xxxxxxxxxx> wrote:
> [...]
> > > I think we will need some callback mechanism for this. Something like:
> > >
> > > for_each_parents(starting_path, root, callback_fn, cb_data, bool try_rcu) {
> > > if (!try_rcu)
> > > goto ref_walk;
> > >
> > > __read_seqcount_begin();
> > > /* rcu walk parents, from starting_path until root */
> > > walk_rcu(starting_path, root, path) {
> > > callback_fn(path, cb_data);
> > > }
> > > if (!read_seqcount_retry())
> > > return xxx; /* successful rcu walk */
> > >
> > > ref_walk:
> > > /* ref walk parents, from starting_path until root */
> > > walk(starting_path, root, path) {
> > > callback_fn(path, cb_data);
> > > }
> > > return xxx;
> > > }
> > >
> > > Personally, I don't like this version very much, because the callback
> > > mechanism is not very flexible, and it is tricky to use it in BPF LSM.
> >
> > Aside from the "exposing mount seqcounts" problem, what do you think about
> > the parent_iterator approach I suggested earlier? I feel that it is
> > better than such a callback - more flexible, and also fits in right with
> > the BPF API you already designed (i.e. with a callback you might then have
> > to allow BPF to pass a callback?). There are some specifics that I can
> > improve - Mickaël suggested some in our discussion:
> >
> > - Letting the caller take rcu_read_lock outside rather than doing it in
> > path_walk_parent_start
> >
> > - Instead of always requiring a struct parent_iterator, allow passing in
> > NULL for the iterator to path_walk_parent to do a reference walk without
> > needing to call path_walk_parent_start - this way might be simpler and
> > path_walk_parent_start/end can just be for rcu case.
> >
> > but what do you think about the overall shape of it?
>
> Personally, I don't have strong objections to this design. But VFS
> folks may have other concerns with it.
