From: Linus Torvalds <torvalds@linux-foundation.org>
To: Borislav Petkov <bp@suse.de>,
Tadeusz Struk <tadeusz.struk@linaro.org>,
"Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: x86-ml <x86@kernel.org>, lkml <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] sched/urgent for 5.17-rc4
Date: Sun, 13 Feb 2022 10:02:22 -0800 [thread overview]
Message-ID: <CAHk-=wiHUWHHcPLCvyXQKf2wbL3L1SOQSGVuCdf-py6QZGnuqQ@mail.gmail.com> (raw)
In-Reply-To: <Ygj7feK+vdtPw6zj@zn.tnic>
On Sun, Feb 13, 2022 at 4:37 AM Borislav Petkov <bp@suse.de> wrote:
>
> Tadeusz Struk (1):
> sched/fair: Fix fault in reweight_entity
I've pulled this, but this really smells bad to me.
If set_load_weight() can see a process that hasn't even had the
runqueue pointer set yet, then what keeps *others* from the same
thing?
Adding a test like this in set_load_weight() just makes me go "what
makes this function so special"? IOW, why could only that function see
this situation with a missing cfs_rq pointer?
I really get the feeling that this is papering over a serious mistake
in how commit 4ef0c5c6b5ba ("kernel/sched: Fix sched_fork() access an
invalid sched_task_group") now causes fundamental process state to be
initialized too late - when the process is already visible to others.
The setpriority() -> dequeue_load_avg() chain just seems to be one
possible case.
*ANYBODY* that does find_task_by_vpid(who) would seem to be able to
find a task that hasn't actually been fully set up yet, and
Somebody tell me why I'm wrong, and what makes that setpriority thing
so magically special. Please.
Linus
next prev parent reply other threads:[~2022-02-13 18:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-13 12:37 [GIT PULL] sched/urgent for 5.17-rc4 Borislav Petkov
2022-02-13 18:02 ` Linus Torvalds [this message]
2022-02-14 8:45 ` Peter Zijlstra
2022-02-14 9:16 ` Peter Zijlstra
2022-02-14 19:17 ` Tejun Heo
2022-02-14 19:35 ` Peter Zijlstra
2022-02-14 19:46 ` Tejun Heo
2022-02-17 8:51 ` [PATCH] sched: Fix yet more sched_fork() races Peter Zijlstra
2022-02-17 10:50 ` Dietmar Eggemann
2022-02-17 12:08 ` Zhang Qiao
2022-02-17 17:33 ` Tadeusz Struk
2022-02-18 6:18 ` Zhang Qiao
2022-02-19 10:14 ` [tip: sched/urgent] " tip-bot2 for Peter Zijlstra
2022-02-13 18:04 ` [GIT PULL] sched/urgent for 5.17-rc4 pr-tracker-bot
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='CAHk-=wiHUWHHcPLCvyXQKf2wbL3L1SOQSGVuCdf-py6QZGnuqQ@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=bp@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=tadeusz.struk@linaro.org \
--cc=x86@kernel.org \
/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).