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. > 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.
