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.
