[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87ilqcuftz.fsf@email.froward.int.ebiederm.org>
Date: Wed, 11 May 2022 12:41:44 -0500
From: "Eric W. Biederman" <ebiederm@...ssion.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: linux-arch@...r.kernel.org, Tejun Heo <tj@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Vincent Guittot <vincent.guittot@...aro.org>,
Al Viro <viro@...IV.linux.org.uk>,
Jens Axboe <axboe@...nel.dk>,
Linus Torvalds <torvalds@...uxfoundation.org>,
linux-kernel@...r.kernel.org, stable@...r.kernel.org,
Максим Кутявин
<maximkabox13@...il.com>
Subject: Re: [PATCH 1/7] kthread: Don't allocate kthread_struct for init and
umh
"Eric W. Biederman" <ebiederm@...ssion.com> writes:
> Thomas Gleixner <tglx@...utronix.de> writes:
>
>> I'm worried that there are more of these issues lurking. Haven't looked
>> yet.
>
> I looked earlier and I missed this one. I am going to look again today,
> along with applying the obvious fix to task_tick_numa.
So I have just looked again and I don't see anything. There are a
couple of subtle issues on x86. Especially with saving floating
point but as I read the code copy_thread initializes things
properly so that code that doesn't touch floating point registers
doesn't need to do anything.
The important thing for lurking issues is that even if I missed
something practically all of the uses of PF_KTHREAD are on x86
or generic code so they should be flushed out quickly.
Eric
Powered by blists - more mailing lists