Re: [PATCH] cgroup: Relax restrictions on kernel threads moving out of root cpu cgroup

dividual kworker > > > can potentially have CPU share equal to the entire UX cgroup. > > > > > > -kworker/0:0 > > > -kworker/1:0 > > > - UX > > > Task-A > > > Task-B > > > - background > > > Task-X > > >

Re: [PATCH] cgroup: Relax restrictions on kernel threads moving out of root cpu cgroup

ps in prioritizing > > Task-A and Task-B over Task-X and Task-Y. However, each individual kworker > > can potentially have CPU share equal to the entire UX cgroup. > > > > -kworker/0:0 > > -kworker/1:0 > > - UX > > ----Task-A > > Task-B > > - ba

Re: [PATCH] cgroup: Relax restrictions on kernel threads moving out of root cpu cgroup

However, each individual kworker > can potentially have CPU share equal to the entire UX cgroup. > > -kworker/0:0 > -kworker/1:0 > - UX > Task-A > Task-B > - background > ----Task-X > Task-Y > Hence we want to move all kernel threads to another cgr

Re: [PATCH] cgroup: Relax restrictions on kernel threads moving out of root cpu cgroup

> are mounted on different hierarchies. > > > > We also see kthreadd_task and any kernel thread created after the Android > > boot > > also stuck in the root cgroup. The current code prevents kthreadd_task > > moving > > out root cgroup to avoid the

Re: [PATCH] cgroup: Relax restrictions on kernel threads moving out of root cpu cgroup

cgroup. The current code prevents kthreadd_task moving > out root cgroup to avoid the possibility of creating new RT kernel threads > inside a cgroup with no RT runtime allocated. Apply this restriction when > tasks > are moving out of cpu cgroup under CONFIG_RT_GROUP_SCHED. T

[PATCH] cgroup: Relax restrictions on kernel threads moving out of root cpu cgroup

are mounted on different hierarchies. We also see kthreadd_task and any kernel thread created after the Android boot also stuck in the root cgroup. The current code prevents kthreadd_task moving out root cgroup to avoid the possibility of creating new RT kernel threads inside a cgroup with no RT runtime

Re: [PATCH] cgroup: Relax restrictions on kernel threads moving out of root cpu cgroup

kthreadd_task and any kernel thread created after the Android > > boot > > also stuck in the root cgroup. The current code prevents kthreadd_task > > moving > > out root cgroup to avoid the possibility of creating new RT kernel threads > > inside a cgroup with no RT

Re: [PATCH] cgroup: Relax restrictions on kernel threads moving out of root cpu cgroup

oup to avoid the possibility of creating new RT kernel threads > inside a cgroup with no RT runtime allocated. Apply this restriction when > tasks > are moving out of cpu cgroup under CONFIG_RT_GROUP_SCHED. This allows all > kernel threads to be moved out of root cpu cgroup if the kernel d

[PATCH] cgroup: Relax restrictions on kernel threads moving out of root cpu cgroup

thread created after the Android boot also stuck in the root cgroup. The current code prevents kthreadd_task moving out root cgroup to avoid the possibility of creating new RT kernel threads inside a cgroup with no RT runtime allocated. Apply this restriction when tasks are moving out of cpu cgroup

Re: [PATCH v4 2/9] x86/kthread,dumpstack: Set task_pt_regs->cs.RPL=3 for kernel threads

On Wed, Mar 17, 2021 at 11:12:41AM -0700, Andy Lutomirski wrote: > @@ -163,6 +163,19 @@ int copy_thread(unsigned long clone_flags, unsigned long > sp, unsigned long arg, > /* Kernel thread ? */ > if (unlikely(p->flags & PF_KTHREAD)) { > memset(childregs, 0, sizeof(struct

[PATCH v4 2/9] x86/kthread,dumpstack: Set task_pt_regs->cs.RPL=3 for kernel threads

For kernel threads, task_pt_regs is currently all zeros, a valid user state (if kernel_execve() has been called), or some combination thereof during execution of kernel_execve(). If a stack trace is printed, the unwinder might get confused and treat task_pt_regs as a kernel state. Indeed

[PATCH 5.11 43/44] tomoyo: recognize kernel threads correctly

s a kernel thread in order to assume that kernel threads are privileged for socket operations was (current->flags & PF_KTHREAD). Now that uaccess_kernel() became 0 on x86, tomoyo has to fix this problem. Do like commit 942cb357ae7d9249 ("Smack: Handle io_uring kernel thread privileg

[PATCH 5.10 41/42] tomoyo: recognize kernel threads correctly

to assume that kernel threads are privileged for socket operations was (current->flags & PF_KTHREAD). Now that uaccess_kernel() became 0 on x86, tomoyo has to fix this problem. Do like commit 942cb357ae7d9249 ("Smack: Handle io_uring kernel thread privileges") does. Signed-off-b

Re: [PATCH v3 04/11] x86/kthread,dumpstack: Set task_pt_regs->cs.RPL=3 for kernel threads

On Thu, Mar 04, 2021 at 11:05:57AM -0800, Andy Lutomirski wrote: > For kernel threads, task_pt_regs is currently all zeros, a valid user state > (if kernel_execve() has been called), or some combination thereof during > execution of kernel_execve(). If a stack trace is printed, the

[PATCH v3 04/11] x86/kthread,dumpstack: Set task_pt_regs->cs.RPL=3 for kernel threads

For kernel threads, task_pt_regs is currently all zeros, a valid user state (if kernel_execve() has been called), or some combination thereof during execution of kernel_execve(). If a stack trace is printed, the unwinder might get confused and treat task_pt_regs as a kernel state. Indeed

[RFC 7/9] x86/mm: Handle tagged memory accesses from kernel threads

When a kernel thread performs memory access on behalf of a process (like in async I/O, io_uring, etc.) it has to respect tagging setup of the process as user addresses can include tags. Normally, LAM setup is per-thread and recorded in thread flags, but for this use case we also track LAM setup

[PATCH 2/3] perf tools: Skip MMAP record synthesis for kernel threads

To synthesize information to resolve sample IPs, it needs to scan task and mmap info from the /proc filesystem. For each process, it opens (and reads) status and maps file respectively. But as kernel threads don't have memory maps so we can skip the maps file. To find kernel threads, check

Re: [PATCH 2/3] perf tools: Skip MMAP record synthesis for kernel threads

> and mmap info from the /proc filesystem. For each process, it > > > opens (and reads) status and maps file respectively. But as kernel > > > threads don't have memory maps so we can skip the maps file. > > > > > > To find kernel threads, check "VmPeak:&qu

Re: [PATCH 2/3] perf tools: Skip MMAP record synthesis for kernel threads

d reads) status and maps file respectively. But as kernel > > threads don't have memory maps so we can skip the maps file. > > > > To find kernel threads, check "VmPeak:" line in /proc//status > > file. It's about the peak virtual memory usage so only user-level >

Re: [PATCH 2/3] perf tools: Skip MMAP record synthesis for kernel threads

On Fri, Jan 29, 2021 at 02:49:00PM +0900, Namhyung Kim wrote: > To synthesize information to resolve sample IPs, it needs to scan task > and mmap info from the /proc filesystem. For each process, it > opens (and reads) status and maps file respectively. But as kernel > threads don't

[PATCH 2/3] perf tools: Skip MMAP record synthesis for kernel threads

To synthesize information to resolve sample IPs, it needs to scan task and mmap info from the /proc filesystem. For each process, it opens (and reads) status and maps file respectively. But as kernel threads don't have memory maps so we can skip the maps file. To find kernel threads, check

Re: [PATCH 2/3] perf tools: Skip MMAP record synthesis for kernel threads

d reads) status and maps file respectively. But as kernel > > threads don't have memory maps so we can skip the maps file. > > > > To find kernel threads, check "VmPeak:" line in /proc//status > > file. It's about the peak virtual memory usage so only user-lev

Re: [PATCH 2/3] perf tools: Skip MMAP record synthesis for kernel threads

On Mon, Dec 21, 2020 at 04:00:28PM +0900, Namhyung Kim wrote: > To synthesize information to resolve sample IPs, it needs to scan task > and mmap info from the /proc filesystem. For each process, it > opens (and reads) status and maps file respectively. But as kernel > threads don't

[PATCH 2/3] perf tools: Skip MMAP record synthesis for kernel threads

To synthesize information to resolve sample IPs, it needs to scan task and mmap info from the /proc filesystem. For each process, it opens (and reads) status and maps file respectively. But as kernel threads don't have memory maps so we can skip the maps file. To find kernel threads, check

[tip: sched/core] isolcpus: Affine unbound kernel threads to housekeeping cpus

Committer: Peter Zijlstra CommitterDate: Mon, 15 Jun 2020 14:10:03 +02:00 isolcpus: Affine unbound kernel threads to housekeeping cpus This is a kernel enhancement that configures the cpu affinity of kernel threads via kernel boot option nohz_full=. When this option is specified, the cpumask

[PATCH 2/2] isolcpus: Affine unbound kernel threads to housekeeping cpus

From: Marcelo Tosatti This is a kernel enhancement that configures the cpu affinity of kernel threads via kernel boot option nohz_full=. When this option is specified, the cpumask is immediately applied upon kthread launch. This does not affect kernel threads that specify cpu and node

Re: [PATCH] kthread: Use TASK_IDLE state for newly created kernel threads

> > > On Wed, May 20, 2020 at 05:25:09PM +0530, Pavankumar Kondeti wrote: > > > > > When kernel threads are created for later use, they will be in > > > > > TASK_UNINTERRUPTIBLE state until they are woken up. This results > > > > > in increase

Re: [PATCH] kthread: Use TASK_IDLE state for newly created kernel threads

On Thu, May 21, 2020 at 07:56:39AM +0200, Greg Kroah-Hartman wrote: > On Thu, May 21, 2020 at 07:05:44AM +0530, Pavan Kondeti wrote: > > On Wed, May 20, 2020 at 08:18:58PM +0200, Greg Kroah-Hartman wrote: > > > On Wed, May 20, 2020 at 05:25:09PM +0530, Pavankumar Kondeti wrote: &

Re: [PATCH] kthread: Use TASK_IDLE state for newly created kernel threads

On Thu, May 21, 2020 at 07:05:44AM +0530, Pavan Kondeti wrote: > On Wed, May 20, 2020 at 08:18:58PM +0200, Greg Kroah-Hartman wrote: > > On Wed, May 20, 2020 at 05:25:09PM +0530, Pavankumar Kondeti wrote: > > > When kernel threads are cre

Re: [PATCH] kthread: Use TASK_IDLE state for newly created kernel threads

On Wed, May 20, 2020 at 08:18:58PM +0200, Greg Kroah-Hartman wrote: > On Wed, May 20, 2020 at 05:25:09PM +0530, Pavankumar Kondeti wrote: > > When kernel threads are created for later use, they will be in > > TASK_UNINTERRUPTIBLE state until they are woken up. This results > >

Re: [PATCH] kthread: Use TASK_IDLE state for newly created kernel threads

On Wed, May 20, 2020 at 05:25:09PM +0530, Pavankumar Kondeti wrote: > When kernel threads are created for later use, they will be in > TASK_UNINTERRUPTIBLE state until they are woken up. This results > in increased loadavg and false hung task reports. To fix this, > use TASK_IDLE s

[PATCH] kthread: Use TASK_IDLE state for newly created kernel threads

When kernel threads are created for later use, they will be in TASK_UNINTERRUPTIBLE state until they are woken up. This results in increased loadavg and false hung task reports. To fix this, use TASK_IDLE state instead of TASK_UNINTERRUPTIBLE when a kernel thread schedules out for the first time

RE: [PATCH 4.19 11/37] PM: hibernate: Freeze kernel threads in software_resume()

> From: Pavel Machek > Sent: Tuesday, May 5, 2020 5:10 AM > To: Greg Kroah-Hartman > Cc: linux-kernel@vger.kernel.org; sta...@vger.kernel.org; Dexuan Cui > ; Rafael J. Wysocki > Subject: Re: [PATCH 4.19 11/37] PM: hibernate: Freeze kernel threads in > software_resume() &

Re: [PATCH 4.19 11/37] PM: hibernate: Freeze kernel threads in software_resume()

Hi! > commit 2351f8d295ed63393190e39c2f7c1fee1a80578f upstream. > > Currently the kernel threads are not frozen in software_resume(), so > between dpm_suspend_start(PMSG_QUIESCE) and resume_target_kernel(), > system_freezable_power_efficient_wq can still try to submit

[PATCH 4.14 14/26] PM: hibernate: Freeze kernel threads in software_resume()

From: Dexuan Cui commit 2351f8d295ed63393190e39c2f7c1fee1a80578f upstream. Currently the kernel threads are not frozen in software_resume(), so between dpm_suspend_start(PMSG_QUIESCE) and resume_target_kernel(), system_freezable_power_efficient_wq can still try to submit SCSI commands

[PATCH 4.19 11/37] PM: hibernate: Freeze kernel threads in software_resume()

From: Dexuan Cui commit 2351f8d295ed63393190e39c2f7c1fee1a80578f upstream. Currently the kernel threads are not frozen in software_resume(), so between dpm_suspend_start(PMSG_QUIESCE) and resume_target_kernel(), system_freezable_power_efficient_wq can still try to submit SCSI commands

[PATCH 5.4 29/57] PM: hibernate: Freeze kernel threads in software_resume()

From: Dexuan Cui commit 2351f8d295ed63393190e39c2f7c1fee1a80578f upstream. Currently the kernel threads are not frozen in software_resume(), so between dpm_suspend_start(PMSG_QUIESCE) and resume_target_kernel(), system_freezable_power_efficient_wq can still try to submit SCSI commands

[PATCH 5.6 35/73] PM: hibernate: Freeze kernel threads in software_resume()

From: Dexuan Cui commit 2351f8d295ed63393190e39c2f7c1fee1a80578f upstream. Currently the kernel threads are not frozen in software_resume(), so between dpm_suspend_start(PMSG_QUIESCE) and resume_target_kernel(), system_freezable_power_efficient_wq can still try to submit SCSI commands

[PATCH 4.9 09/18] PM: hibernate: Freeze kernel threads in software_resume()

From: Dexuan Cui commit 2351f8d295ed63393190e39c2f7c1fee1a80578f upstream. Currently the kernel threads are not frozen in software_resume(), so between dpm_suspend_start(PMSG_QUIESCE) and resume_target_kernel(), system_freezable_power_efficient_wq can still try to submit SCSI commands

Re: [PATCH] sched/core: Don't use dying mm as active_mm for kernel threads

/Waiman-Long/sched-core-Don-t-use-dying-mm-as-active_mm-for-kernel-threads/20190728-101948 config: i386-allnoconfig (attached as .config) compiler: gcc-7 (Debian 7.4.0-10) 7.4.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 If you fix the issue, kindly add

Re: [PATCH] sched/core: Don't use dying mm as active_mm for kernel threads

/Waiman-Long/sched-core-Don-t-use-dying-mm-as-active_mm-for-kernel-threads/20190728-101948 config: x86_64-randconfig-s1-07280001 (attached as .config) compiler: gcc-4.9 (Debian 4.9.2-10+deb8u1) 4.9.2 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 If you

Re: [PATCH] sched/core: Don't use dying mm as active_mm for kernel threads

On 7/26/19 7:45 PM, Waiman Long wrote: > It was found that a dying mm_struct where the owning task has exited can > stay on as active_mm of kernel threads as long as no other user tasks > run on those CPUs that use it as active_mm. This prolongs the life time > of dying mm holdi

[PATCH] sched/core: Don't use dying mm as active_mm for kernel threads

It was found that a dying mm_struct where the owning task has exited can stay on as active_mm of kernel threads as long as no other user tasks run on those CPUs that use it as active_mm. This prolongs the life time of dying mm holding up memory and other resources that cannot be freed. Fix

[tip:core/stacktrace] stacktrace: Use PF_KTHREAD to check for kernel threads

PF_KTHREAD to check for kernel threads !current->mm is not a reliable indicator for kernel threads as they might temporarily use a user mm. Check for PF_KTHREAD instead. Signed-off-by: Thomas Gleixner Acked-by: Mark Rutland Cc: Josh Poimboeuf Cc: Peter Zijlstra Cc: Steven Rostedt Link: ht

Re: [PATCH] stacktrace: Use PF_KTHREAD to check for kernel threads

On Tue, Jul 02, 2019 at 05:53:35PM +0200, Thomas Gleixner wrote: > !current->mm is not a reliable indicator for kernel threads as they might > temporarily use a user mm. Check for PF_KTHREAD instead. > > Signed-off-by: Thomas Gleixner FWIW: Acked-by: Mark Rutland As a head

[PATCH] stacktrace: Use PF_KTHREAD to check for kernel threads

!current->mm is not a reliable indicator for kernel threads as they might temporarily use a user mm. Check for PF_KTHREAD instead. Signed-off-by: Thomas Gleixner --- --- a/kernel/stacktrace.c +++ b/kernel/stacktrace.c @@ -228,7 +228,7 @@ unsigned int stack_trace_save_user(un

[RFC v2 1/5] cgroup: add cgroup v2 interfaces to migrate kernel threads

Prepare for cgroup aware workqueues by introducing cgroup_attach_kthread and a helper cgroup_attach_kthread_to_dfl_root. A workqueue worker will always migrate itself, so for now use @current in the interfaces to avoid handling task references. Signed-off-by: Daniel Jordan ---

Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

On 10/19/2018 10:37 AM, Andy Lutomirski wrote: >> I think it's much more straightforward to just not enforce pkeys. >> Having this "phantom" value could cause a very odd, nearly >> undebuggable I/O failure. > But now we have the reverse. The IO can work if it’s truly async but, > if the kernel

Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

On 10/19/2018 10:37 AM, Andy Lutomirski wrote: >> I think it's much more straightforward to just not enforce pkeys. >> Having this "phantom" value could cause a very odd, nearly >> undebuggable I/O failure. > But now we have the reverse. The IO can work if it’s truly async but, > if the kernel

Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

> On Oct 19, 2018, at 10:01 AM, Dave Hansen wrote: > > On 10/19/2018 09:59 AM, Andy Lutomirski wrote: >>> That looks like a good API in general. The ffs_user_copy_worker that >>> Sebastian mentioned seems to be used by AIO, in which case of course it >>> has to happen in a kernel thread. >>>

Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

> On Oct 19, 2018, at 10:01 AM, Dave Hansen wrote: > > On 10/19/2018 09:59 AM, Andy Lutomirski wrote: >>> That looks like a good API in general. The ffs_user_copy_worker that >>> Sebastian mentioned seems to be used by AIO, in which case of course it >>> has to happen in a kernel thread. >>>

Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

On 10/19/2018 09:59 AM, Andy Lutomirski wrote: >> That looks like a good API in general. The ffs_user_copy_worker that >> Sebastian mentioned seems to be used by AIO, in which case of course it >> has to happen in a kernel thread. >> >> But while the API is good, deciding on the desired semantics

Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

On 10/19/2018 09:59 AM, Andy Lutomirski wrote: >> That looks like a good API in general. The ffs_user_copy_worker that >> Sebastian mentioned seems to be used by AIO, in which case of course it >> has to happen in a kernel thread. >> >> But while the API is good, deciding on the desired semantics

Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

> On Oct 19, 2018, at 12:44 AM, Paolo Bonzini wrote: > > On 18/10/2018 22:46, Andy Lutomirski wrote: >>> [0] drivers/usb/gadget/function/f_fs.c::ffs_user_copy_worker() >>> >>> Sebastian >> I think we need an entirely new API: >> >> user_mm_ctx_t ctx = user_mm_ctx_get(); >> >> ... >> >>

Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

> On Oct 19, 2018, at 12:44 AM, Paolo Bonzini wrote: > > On 18/10/2018 22:46, Andy Lutomirski wrote: >>> [0] drivers/usb/gadget/function/f_fs.c::ffs_user_copy_worker() >>> >>> Sebastian >> I think we need an entirely new API: >> >> user_mm_ctx_t ctx = user_mm_ctx_get(); >> >> ... >> >>

Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

On 18/10/2018 22:46, Andy Lutomirski wrote: >> [0] drivers/usb/gadget/function/f_fs.c::ffs_user_copy_worker() >> >> Sebastian > I think we need an entirely new API: > > user_mm_ctx_t ctx = user_mm_ctx_get(); > > ... > > use_user_mm_ctx(ctx); > unuse_user_mm_ctx(ctx); > > ... > >

Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

On 18/10/2018 22:46, Andy Lutomirski wrote: >> [0] drivers/usb/gadget/function/f_fs.c::ffs_user_copy_worker() >> >> Sebastian > I think we need an entirely new API: > > user_mm_ctx_t ctx = user_mm_ctx_get(); > > ... > > use_user_mm_ctx(ctx); > unuse_user_mm_ctx(ctx); > > ... > >

Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

t;> >> Bypassing protection keys is not a big deal IMNHO. In places where a >> sane one is not readily available, I'm totally fine with just >> effectively disabling it (PKRU=0) for the length of time it isn't available. > > Okay, this makes things easier. Let document that

Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

t;> >> Bypassing protection keys is not a big deal IMNHO. In places where a >> sane one is not readily available, I'm totally fine with just >> effectively disabling it (PKRU=0) for the length of time it isn't available. > > Okay, this makes things easier. Let document that

Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

not readily available, I'm totally fine with just > effectively disabling it (PKRU=0) for the length of time it isn't available. Okay, this makes things easier. Let document that for kernel threads we use PKRU=0. This should be happening in my try right now. I double check tomorrow just in case… Sebastian

Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

not readily available, I'm totally fine with just > effectively disabling it (PKRU=0) for the length of time it isn't available. Okay, this makes things easier. Let document that for kernel threads we use PKRU=0. This should be happening in my try right now. I double check tomorrow just in case… Sebastian

Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

On 10/18/2018 01:46 PM, Andy Lutomirski wrote: > Setting it to allow-all/none would let the operation always fail or > succeed which might be an improvement in terms of debugging. However it > is hard to judge what the correct behaviour should be. Should fail or > succeed. Succeed. :) > But this

Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

On 10/18/2018 01:46 PM, Andy Lutomirski wrote: > Setting it to allow-all/none would let the operation always fail or > succeed which might be an improvement in terms of debugging. However it > is hard to judge what the correct behaviour should be. Should fail or > succeed. Succeed. :) > But this

Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

On Thu, Oct 18, 2018 at 11:25 AM Sebastian Andrzej Siewior wrote: > > On 2018-10-18 09:48:24 [-0700], Andy Lutomirski wrote: > > > On Oct 18, 2018, at 9:26 AM, Sebastian Andrzej Siewior > > > wrote: > > >> On 2018-10-12 11:02:18 [-0700], Andy Lutomirski wrote: > > >> On Fri, Oct 12, 2018 at

Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

On Thu, Oct 18, 2018 at 11:25 AM Sebastian Andrzej Siewior wrote: > > On 2018-10-18 09:48:24 [-0700], Andy Lutomirski wrote: > > > On Oct 18, 2018, at 9:26 AM, Sebastian Andrzej Siewior > > > wrote: > > >> On 2018-10-12 11:02:18 [-0700], Andy Lutomirski wrote: > > >> On Fri, Oct 12, 2018 at

Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

On 2018-10-18 09:48:24 [-0700], Andy Lutomirski wrote: > > On Oct 18, 2018, at 9:26 AM, Sebastian Andrzej Siewior > > wrote: > >> On 2018-10-12 11:02:18 [-0700], Andy Lutomirski wrote: > >> On Fri, Oct 12, 2018 at 10:54 AM Dave Hansen > >>> So I'm kinda missing the point of the patch. > >> > >>

Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

On 2018-10-18 09:48:24 [-0700], Andy Lutomirski wrote: > > On Oct 18, 2018, at 9:26 AM, Sebastian Andrzej Siewior > > wrote: > >> On 2018-10-12 11:02:18 [-0700], Andy Lutomirski wrote: > >> On Fri, Oct 12, 2018 at 10:54 AM Dave Hansen > >>> So I'm kinda missing the point of the patch. > >> > >>

Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

On 10/18/2018 09:48 AM, Andy Lutomirski wrote: >>>> We might want to do this for cleanliness reasons... Maybe. >>>> >>>> But this *should* have no practical effects. Kernel threads have no >>>> real 'mm' and no user pages. They should not have d

Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

On 10/18/2018 09:48 AM, Andy Lutomirski wrote: >>>> We might want to do this for cleanliness reasons... Maybe. >>>> >>>> But this *should* have no practical effects. Kernel threads have no >>>> real 'mm' and no user pages. They should not have d

Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

ej Siewior wrote: >>>> The PKRU value is not set for kernel threads because they do not have >>>> the ->initialized value set. As a result the kernel thread has a random >>>> PKRU value set which it inherits from the previous task. >>>> It has been suggest

Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

ej Siewior wrote: >>>> The PKRU value is not set for kernel threads because they do not have >>>> the ->initialized value set. As a result the kernel thread has a random >>>> PKRU value set which it inherits from the previous task. >>>> It has been suggest

Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

On 2018-10-12 11:02:18 [-0700], Andy Lutomirski wrote: > On Fri, Oct 12, 2018 at 10:54 AM Dave Hansen > wrote: > > > > On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote: > > > The PKRU value is not set for kernel threads because they do not have > &

Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

On 2018-10-12 11:02:18 [-0700], Andy Lutomirski wrote: > On Fri, Oct 12, 2018 at 10:54 AM Dave Hansen > wrote: > > > > On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote: > > > The PKRU value is not set for kernel threads because they do not have > &

Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

On Fri, Oct 12, 2018 at 10:54 AM Dave Hansen wrote: > > On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote: > > The PKRU value is not set for kernel threads because they do not have > > the ->initialized value set. As a result the kernel thread has a random >

Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

On Fri, Oct 12, 2018 at 10:54 AM Dave Hansen wrote: > > On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote: > > The PKRU value is not set for kernel threads because they do not have > > the ->initialized value set. As a result the kernel thread has a random >

Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote: > The PKRU value is not set for kernel threads because they do not have > the ->initialized value set. As a result the kernel thread has a random > PKRU value set which it inherits from the previous task. > It has been sug

Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote: > The PKRU value is not set for kernel threads because they do not have > the ->initialized value set. As a result the kernel thread has a random > PKRU value set which it inherits from the previous task. > It has been sug

[PATCH 05/11] x86/fpu: set PKRU state for kernel threads

The PKRU value is not set for kernel threads because they do not have the ->initialized value set. As a result the kernel thread has a random PKRU value set which it inherits from the previous task. It has been suggested by Paolo Bonzini to set it for kernel threads, too because it might be a

[PATCH 05/11] x86/fpu: set PKRU state for kernel threads

The PKRU value is not set for kernel threads because they do not have the ->initialized value set. As a result the kernel thread has a random PKRU value set which it inherits from the previous task. It has been suggested by Paolo Bonzini to set it for kernel threads, too because it might be a

Re: [PATCH v2 06/17] x86/ldt: Do not install LDT for kernel threads

On Thu, Dec 14, 2017 at 11:43 AM, Peter Zijlstra <pet...@infradead.org> wrote: > On Thu, Dec 14, 2017 at 12:27:32PM +0100, Peter Zijlstra wrote: >> From: Thomas Gleixner <t...@linutronix.de> >> >> Kernel threads can use the mm of a user process temporarily via u

Re: [PATCH v2 06/17] x86/ldt: Do not install LDT for kernel threads

On Thu, Dec 14, 2017 at 11:43 AM, Peter Zijlstra wrote: > On Thu, Dec 14, 2017 at 12:27:32PM +0100, Peter Zijlstra wrote: >> From: Thomas Gleixner >> >> Kernel threads can use the mm of a user process temporarily via use_mm(), >> but there is no point in installing

Re: [PATCH v2 06/17] x86/ldt: Do not install LDT for kernel threads

On Thu, Dec 14, 2017 at 12:27:32PM +0100, Peter Zijlstra wrote: > From: Thomas Gleixner <t...@linutronix.de> > > Kernel threads can use the mm of a user process temporarily via use_mm(), > but there is no point in installing the LDT which is associated to that mm > for t

Re: [PATCH v2 06/17] x86/ldt: Do not install LDT for kernel threads

On Thu, Dec 14, 2017 at 12:27:32PM +0100, Peter Zijlstra wrote: > From: Thomas Gleixner > > Kernel threads can use the mm of a user process temporarily via use_mm(), > but there is no point in installing the LDT which is associated to that mm > for the kernel thread. So

[PATCH v2 06/17] x86/ldt: Do not install LDT for kernel threads

From: Thomas Gleixner <t...@linutronix.de> Kernel threads can use the mm of a user process temporarily via use_mm(), but there is no point in installing the LDT which is associated to that mm for the kernel thread. Signed-off-by: Thomas Gleixner <t...@linutronix.de> --- arch/x86

[PATCH v2 06/17] x86/ldt: Do not install LDT for kernel threads

From: Thomas Gleixner Kernel threads can use the mm of a user process temporarily via use_mm(), but there is no point in installing the LDT which is associated to that mm for the kernel thread. Signed-off-by: Thomas Gleixner --- arch/x86/include/asm/mmu_context.h |3 +-- 1 file changed, 1

Re: [patch 10/16] x86/ldt: Do not install LDT for kernel threads

On Tue, Dec 12, 2017 at 9:32 AM, Thomas Gleixner <t...@linutronix.de> wrote: > From: Thomas Gleixner <t...@linutronix.de> > > Kernel threads can use the mm of a user process temporarily via use_mm(), > but there is no point in installing the LDT which is associated to

Re: [patch 10/16] x86/ldt: Do not install LDT for kernel threads

On Tue, Dec 12, 2017 at 9:32 AM, Thomas Gleixner wrote: > From: Thomas Gleixner > > Kernel threads can use the mm of a user process temporarily via use_mm(), > but there is no point in installing the LDT which is associated to that mm > for the kernel thread. > I like this one.

[patch 10/16] x86/ldt: Do not install LDT for kernel threads

From: Thomas Gleixner <t...@linutronix.de> Kernel threads can use the mm of a user process temporarily via use_mm(), but there is no point in installing the LDT which is associated to that mm for the kernel thread. Signed-off-by: Thomas Gleixner <t...@linutronix.de> --- arch/x86

[patch 10/16] x86/ldt: Do not install LDT for kernel threads

From: Thomas Gleixner Kernel threads can use the mm of a user process temporarily via use_mm(), but there is no point in installing the LDT which is associated to that mm for the kernel thread. Signed-off-by: Thomas Gleixner --- arch/x86/include/asm/mmu_context.h |3 +-- 1 file changed, 1

Re: [RFC][PATCHv4 0/7] printk: introduce printing kernel threads

On (06/30/17 14:11), Petr Mladek wrote: > > 2) can offload printing to other CPUs from vprintk_emit() > >and avoid any of scheduler->timekeeping->etc. paths. which will > >replace printk_deferred(). > > I probably miss something. There is still called wake_up_process() > in this patchset

Re: [RFC][PATCHv4 0/7] printk: introduce printing kernel threads

On (06/30/17 14:11), Petr Mladek wrote: > > 2) can offload printing to other CPUs from vprintk_emit() > >and avoid any of scheduler->timekeeping->etc. paths. which will > >replace printk_deferred(). > > I probably miss something. There is still called wake_up_process() > in this patchset

Re: [RFC][PATCHv4 0/7] printk: introduce printing kernel threads

On Thu 2017-06-29 16:56:30, Sergey Senozhatsky wrote: > yeah, I agree and understand that per-CPU printk kthreads > is a bit... too much. > > it was just a quick idea and I just gave it a try. but there > are some potential takeaways from the series (not sure if you > looked at the last patches

Re: [RFC][PATCHv4 0/7] printk: introduce printing kernel threads

On Thu 2017-06-29 16:56:30, Sergey Senozhatsky wrote: > yeah, I agree and understand that per-CPU printk kthreads > is a bit... too much. > > it was just a quick idea and I just gave it a try. but there > are some potential takeaways from the series (not sure if you > looked at the last patches

Re: [RFC][PATCHv4 0/7] printk: introduce printing kernel threads

On (06/28/17 15:42), Petr Mladek wrote: [..] > My head is whirling when thinking about all the per-CPU stuff. It is > looking for escape. The way is to keep it as simple as possible. > > After all, we should need all this only when there is a flood of > messages. Otherwise, the messages should be

Re: [RFC][PATCHv4 0/7] printk: introduce printing kernel threads

On (06/28/17 15:42), Petr Mladek wrote: [..] > My head is whirling when thinking about all the per-CPU stuff. It is > looking for escape. The way is to keep it as simple as possible. > > After all, we should need all this only when there is a flood of > messages. Otherwise, the messages should be

Re: [RFC][PATCHv4 0/7] printk: introduce printing kernel threads

On Thu 2017-06-08 17:18:29, Sergey Senozhatsky wrote: > we still don't have guarantees that printk_kthread will be scheduled on > a CPU that can run it immediately or anytime in the future, but not too > late. printk_kthread can even be scheduled on the CPU that has requested > offloading in the

Re: [RFC][PATCHv4 0/7] printk: introduce printing kernel threads

On Thu 2017-06-08 17:18:29, Sergey Senozhatsky wrote: > we still don't have guarantees that printk_kthread will be scheduled on > a CPU that can run it immediately or anytime in the future, but not too > late. printk_kthread can even be scheduled on the CPU that has requested > offloading in the

[PATCH 3.10 166/268] s390: TASK_SIZE for kernel threads

From: Martin Schwidefsky commit fb94a687d96c570d46332a4a890f1dcb7310e643 upstream. Return a sensible value if TASK_SIZE if called from a kernel thread. This gets us around an issue with copy_mount_options that does a magic size calculation "TASK_SIZE - (unsigned

[PATCH 3.10 166/268] s390: TASK_SIZE for kernel threads

From: Martin Schwidefsky commit fb94a687d96c570d46332a4a890f1dcb7310e643 upstream. Return a sensible value if TASK_SIZE if called from a kernel thread. This gets us around an issue with copy_mount_options that does a magic size calculation "TASK_SIZE - (unsigned long)data" while in a kernel

Re: [RFC][PATCHv4 0/7] printk: introduce printing kernel threads

Hello, On (06/02/17 18:03), Sergey Senozhatsky wrote: [..] > I've managed to reproduce some of the issues with a single printk > kthread solution that Jan Kara talked about. Sometimes scheduler decides > sometimes scheduler decides that printk kthread should run on the same CPU > as the

  1   2   3   4   5   6   7   8   >