On Thu, Nov 17, 2022 at 11:34 PM Martin KaFai Lau <martin.lau@xxxxxxxxx> wrote: > > On 11/17/22 5:52 PM, Hou Tao wrote: > > Hi, > > > > On 11/17/2022 2:48 PM, Martin KaFai Lau wrote: <...> > > Rather than adding the above logic for iterator link, just pinning the start > > cgroup in .init_seq_private() will be much simpler. > > Yeah, it is better to fix the bug without changing the behavior when all the > link fds are closed and pinned files are removed. In particular this will make > the link iter works differently from other link types. > > I can see pinning a link inside an iter is a generic solution for all iter types > but lets continue to explore other ways to refactor this within the kernel if it > is really needed instead of leaking it to the user space. (not saying this > refactoring belongs to the same patch set. lets fix the current bug first.) > > > prepare_seq_file() has already acquired an extra reference of the currently > > attached program, so it is OK to read the iterator after the close of iterator > > link fd. So what do you think ? > > Right, it is my understanding also that the prog refcnt has been acquired during > the iter creation. Sounds good to me. The fact that the iter holds a reference to the program is what I missed in my reply. Both solutions are correct. Because of that, I don't have a strong opinion on either of them now. :)