Re: [PATCH 3/6] bpf: task_group_seq_get_next: fix the skip_if_dup_files check

[Yonghong Song]

On 8/30/23 7:54 PM, Oleg Nesterov wrote:
> On 08/28, Yonghong Song wrote:
> > On 8/28/23 3:54 AM, Oleg Nesterov wrote:
> > > Could you review 6/6 as well?
> >
> > I think we can wait patch 6/6 after
> >     https://lore.kernel.org/all/20230824143142.GA31222@xxxxxxxxxx/
> > is merged.
>
> OK.
>
> > > Should I fold 1-5 into a single patch? I tried to document every change
> > > and simplify the review, but I do not want to blow the git history.
> >
> > Currently, because patch 6, the whole patch set cannot be tested by
> > bpf CI since it has a build failure:
> >    https://github.com/kernel-patches/bpf/pull/5580
>
> Heh. I thought this is obvious. I thought you can test 1-5 without 6/6
> and _review_ 6/6.
>
> I simply can't understand how can this pull/5580 come when I specially
> mentioned
>
> 	> 6/6 obviously depends on
> 	>
> 	>	[PATCH 1/2] introduce __next_thread(), fix next_tid() vs exec() race
> 	>	https://lore.kernel.org/all/20230824143142.GA31222@xxxxxxxxxx/
> 	>
> 	> which was not merged yet.
>
> in 0/6.

The process in CI for testing is fully automated, and it does
not look at commit message. That is why it takes the whole
series. This is true for all other patch set.

> > I suggest you get patch 1-5 and resubmit with tag like
> >    "bpf-next v2"
> >    [Patch bpf-next v2 x/5] ...
> > so CI can build with different architectures and compilers to
> > ensure everything builds and runs fine.
>
> I think we can wait for
>
> 	https://lore.kernel.org/all/20230824143142.GA31222@xxxxxxxxxx/
>
> as you suggest above, then I'll send the s/next_thread/__next_thread/
> oneliner without 1-5. I no longer think it makes sense to try to cleanup
> the poor task_group_seq_get_next() when IMHO the whole task_iter logic
> needs the complete rewrite. Yes, yes, I know, it is very easy to blame
> someone else's code, sorry can't resist ;)
>
> The only "fix" in this series is 3/6, but this code has more serious
> bugs, so I guess we can forget it.
>
> Oleg.