linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yonghong Song <yonghong.song@linux.dev>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Yonghong Song <yhs@fb.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Kui-Feng Lee <kuifeng@fb.com>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@kernel.org>,
	bpf@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/6] bpf: task_group_seq_get_next: fix the skip_if_dup_files check
Date: Thu, 31 Aug 2023 07:29:38 -0400	[thread overview]
Message-ID: <0261d27e-f9b5-c0fe-1bae-2b76062e7386@linux.dev> (raw)
In-Reply-To: <20230830235459.GA3570@redhat.com>



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@redhat.com/
>> 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@redhat.com/
> 	>
> 	> 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@redhat.com/
> 
> 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.
> 

  reply	other threads:[~2023-08-31 11:29 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-25 16:18 [PATCH 0/6] bpf: task_group_seq_get_next: use __next_thread() Oleg Nesterov
2023-08-25 16:19 ` [PATCH 1/6] bpf: task_group_seq_get_next: cleanup the usage of next_thread() Oleg Nesterov
2023-08-25 22:45   ` Yonghong Song
2023-08-25 16:19 ` [PATCH 2/6] bpf: task_group_seq_get_next: cleanup the usage of get/put_task_struct Oleg Nesterov
2023-08-25 16:19 ` [PATCH 3/6] bpf: task_group_seq_get_next: fix the skip_if_dup_files check Oleg Nesterov
2023-08-25 17:04   ` Oleg Nesterov
2023-08-25 22:52     ` Yonghong Song
2023-08-27 20:19       ` Oleg Nesterov
2023-08-28  1:18         ` Yonghong Song
2023-08-28 10:54           ` Oleg Nesterov
2023-08-29  0:30             ` Yonghong Song
2023-08-30 23:54               ` Oleg Nesterov
2023-08-31 11:29                 ` Yonghong Song [this message]
2023-08-31 12:06                   ` Oleg Nesterov
2023-08-25 22:49   ` Yonghong Song
2023-08-25 16:19 ` [PATCH 4/6] bpf: task_group_seq_get_next: kill next_task Oleg Nesterov
2023-08-25 22:55   ` Yonghong Song
2023-08-25 16:19 ` [PATCH 5/6] bpf: task_group_seq_get_next: simplify the "next tid" logic Oleg Nesterov
2023-08-25 22:57   ` Yonghong Song
2023-08-25 16:19 ` [PATCH 6/6] bpf: task_group_seq_get_next: use __next_thread() rather than next_thread() Oleg Nesterov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0261d27e-f9b5-c0fe-1bae-2b76062e7386@linux.dev \
    --to=yonghong.song@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=andrii@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=ebiederm@xmission.com \
    --cc=kuifeng@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@kernel.org \
    --cc=oleg@redhat.com \
    --cc=torvalds@linux-foundation.org \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).