From: "Eric W. Biederman" <ebiederm@xmission.com>
To: Qian Cai <quic_qiancai@quicinc.com>
Cc: <linux-arch@vger.kernel.org>, Tejun Heo <tj@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Al Viro <viro@ZenIV.linux.org.uk>, Jens Axboe <axboe@kernel.dk>,
Thomas Gleixner <tglx@linutronix.de>,
Linus Torvalds <torvalds@linuxfoundation.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/7] fork: Make init and umh ordinary tasks
Date: Mon, 09 May 2022 16:52:07 -0500 [thread overview]
Message-ID: <87r152xtko.fsf@email.froward.int.ebiederm.org> (raw)
In-Reply-To: <20220509204654.GA200@qian> (Qian Cai's message of "Mon, 9 May 2022 16:46:54 -0400")
Qian Cai <quic_qiancai@quicinc.com> writes:
> On Fri, May 06, 2022 at 09:11:36AM -0500, Eric W. Biederman wrote:
>>
>> In commit 40966e316f86 ("kthread: Ensure struct kthread is present for
>> all kthreads") caused init and the user mode helper threads that call
>> kernel_execve to have struct kthread allocated for them.
>>
>> I believe my first patch in this series is enough to fix the bug
>> and is simple enough and obvious enough to be backportable.
>>
>> The rest of the changes pass struct kernel_clone_args to clean things
>> up and cause the code to make sense.
>>
>> There is one rough spot in this change. In the init process before the
>> user space init process is exec'd there is a lot going on. I have found
>> when async_schedule_domain is low on memory or has more than 32K callers
>> executing do_populate_rootfs will now run in a user space thread making
>> flush_delayed_fput meaningless, and __fput_sync is unusable. I solved
>> this as I did in usermode_driver.c with an added explicit task_work_run.
>> I point this out as I have seen some talk about making flushing file
>> handles more explicit.
>
> Reverting the last 3 commits of the series fixed a boot crash.
>
> 1b2552cbdbe0 fork: Stop allowing kthreads to call execve
> 753550eb0ce1 fork: Explicitly set PF_KTHREAD
> 68d85f0a33b0 init: Deal with the init process being a user mode process
Hmm. It looks like I missed a little detail.
task_tick_fair
task_tick_numa
task_scan_start
task_scan_min
task_nr_scan_windows
p->mm
If I read this code right task_tick_numa makes the assumption that only
tasks with PF_KTHREAD set don't have an mm.
This should fix the failure. For init we could possibly populate .mm
and not just .active_mm. For user mode helpers cloned from kernel
threads I don't think that is a realistic option. So I think this
is going to be the proper fix.
I believe this only happens when numa rebalancing happens at an
unfortunate moment.
Qian Cai can you test this?
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index d4bd299d67ab..db6f0df9d43e 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2915,7 +2915,7 @@ static void task_tick_numa(struct rq *rq, struct task_struct *curr)
/*
* We don't care about NUMA placement if we don't have memory.
*/
- if ((curr->flags & (PF_EXITING | PF_KTHREAD)) || work->next != work)
+ if (!curr->mm || (curr->flags & (PF_EXITING | PF_KTHREAD)) || work->next != work)
return;
/*
Eric
next prev parent reply other threads:[~2022-05-09 21:55 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CANpfEhOnNZa5d_G3e0dzzbbEtSuqxWY-fUCqzSiFpiQ2k0hJyw@mail.gmail.com>
[not found] ` <CAHk-=wjfecvcUk2vNQM1GiUz_G=WQEJ8i8JS7yjnxjq_f-OgKw@mail.gmail.com>
[not found] ` <87a6czifo7.fsf@email.froward.int.ebiederm.org>
[not found] ` <CAHk-=wj=EHvH-DEUHbkoB3vDZJ1xRzrk44JibtNOepNkachxPw@mail.gmail.com>
[not found] ` <87ilrn1drx.ffs@tglx>
[not found] ` <877d7zk1cf.ffs@tglx>
[not found] ` <CAHk-=wiJPeANKYU4imYaeEuV6sNP+EDR=rWURSKv=y4Mhcn1hA@mail.gmail.com>
[not found] ` <87y20fid4d.ffs@tglx>
[not found] ` <87bkx5q3pk.fsf_-_@email.froward.int.ebiederm.org>
2022-05-06 14:11 ` [PATCH 0/7] fork: Make init and umh ordinary tasks Eric W. Biederman
2022-05-06 14:15 ` [PATCH 1/7] kthread: Don't allocate kthread_struct for init and umh Eric W. Biederman
[not found] ` <CANpfEhNAQvazzCSN-dVgYmwNSRjqOrqZF0_j7GPLbCdEkogzSg@mail.gmail.com>
2022-05-06 20:53 ` Eric W. Biederman
2022-05-10 14:38 ` Thomas Gleixner
2022-05-10 15:14 ` Eric W. Biederman
2022-05-11 17:41 ` Eric W. Biederman
2022-05-06 14:15 ` [PATCH 2/7] fork: Pass struct kernel_clone_args into copy_thread Eric W. Biederman
2022-05-06 20:38 ` kernel test robot
2022-05-06 21:52 ` Eric W. Biederman
2022-05-06 21:52 ` Eric W. Biederman
2022-05-06 14:15 ` [PATCH 3/7] fork: Explicity test for idle tasks in copy_thread Eric W. Biederman
2022-05-06 14:15 ` [PATCH 4/7] fork: Generalize PF_IO_WORKER handling Eric W. Biederman
2022-05-06 14:15 ` [PATCH 5/7] init: Deal with the init process being a user mode process Eric W. Biederman
2022-05-06 14:15 ` [PATCH 6/7] fork: Explicitly set PF_KTHREAD Eric W. Biederman
2022-05-06 14:15 ` [PATCH 7/7] fork: Stop allowing kthreads to call execve Eric W. Biederman
2022-05-09 20:46 ` [PATCH 0/7] fork: Make init and umh ordinary tasks Qian Cai
2022-05-09 21:52 ` Eric W. Biederman [this message]
2022-05-10 15:36 ` Qian Cai
2022-05-11 17:37 ` [PATCH 8/7] sched: Update task_tick_numa to ignore tasks without an mm Eric W. Biederman
2022-05-11 17:42 ` Linus Torvalds
2022-05-11 17:53 ` Eric W. Biederman
2022-05-11 17:59 ` Linus Torvalds
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=87r152xtko.fsf@email.froward.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=axboe@kernel.dk \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=quic_qiancai@quicinc.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=torvalds@linuxfoundation.org \
--cc=vincent.guittot@linaro.org \
--cc=viro@ZenIV.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.