Re: [PATCH 1/4] pid: Replace pid bitmap implementation with IDR API

is the idr_get_cursor function, but you would still have to subtract 1 from the value returned by idr_get_cursor... Other than that nitpick, this patch looks good to me. Reviewed-by: Rik van Riel <r...@redhat.com> kind regards, Rik van Riel -- All Rights Reversed. signature.asc Description: This is a digitally signed message part

Re: [PATCH 1/4] pid: Replace pid bitmap implementation with IDR API

nction, but you would still have to subtract 1 from the value returned by idr_get_cursor... Other than that nitpick, this patch looks good to me. Reviewed-by: Rik van Riel kind regards, Rik van Riel -- All Rights Reversed. signature.asc Description: This is a digitally signed message part

Re: [PATCH] mm: madvise: add description for MADV_WIPEONFORK and MADV_KEEPONFORK

the > consistency with other flags. > > Signed-off-by: Yang Shi <yan...@alibaba-inc.com> > Thank you for spotting that I missed a location! Reviewed-by: Rik van Riel <r...@redhat.com>

Re: [PATCH] mm: madvise: add description for MADV_WIPEONFORK and MADV_KEEPONFORK

the > consistency with other flags. > > Signed-off-by: Yang Shi > Thank you for spotting that I missed a location! Reviewed-by: Rik van Riel

Re: [kernel-hardening] [PATCH v3 3/3] x86/fpu: reinitialize FPU registers if restoring FPU state fails

t being restored, sometimes the FPU registers will > have > the values from another process. > Reviewed-by: Rik van Riel <r...@redhat.com> -- All rights reversed signature.asc Description: This is a digitally signed message part

Re: [kernel-hardening] [PATCH v3 3/3] x86/fpu: reinitialize FPU registers if restoring FPU state fails

FPU registers will > have > the values from another process. > Reviewed-by: Rik van Riel -- All rights reversed signature.asc Description: This is a digitally signed message part

Re: [kernel-hardening] [PATCH v3 2/3] x86/fpu: tighten validation of user-supplied xstate_header

hua...@intel.com> > Cc: Ingo Molnar <mi...@kernel.org> > Cc: Kevin Hao <haoke...@gmail.com> > Cc: Oleg Nesterov <o...@redhat.com> > Cc: Wanpeng Li <wanpeng...@hotmail.com> > Cc: Yu-cheng Yu <yu-cheng...@intel.com> > Signed-off-by: Eric Biggers <ebigg...@google.com> > Reviewed-by: Rik van Riel <r...@redhat.com> -- All rights reversed signature.asc Description: This is a digitally signed message part

Re: [kernel-hardening] [PATCH v3 2/3] x86/fpu: tighten validation of user-supplied xstate_header

never know...) > > Reviewed-by: Kees Cook > Acked-by: Dave Hansen > Cc: Andy Lutomirski > Cc: Dmitry Vyukov > Cc: Fenghua Yu > Cc: Ingo Molnar > Cc: Kevin Hao > Cc: Oleg Nesterov > Cc: Wanpeng Li > Cc: Yu-cheng Yu > Signed-off-by: Eric Big

Re: [kernel-hardening] [PATCH v3 1/3] x86/fpu: don't let userspace set bogus xcomp_bv

On Thu, 2017-09-21 at 11:52 -0700, Eric Biggers wrote: > From: Eric Biggers <ebigg...@google.com> > > Fix the bug by checking that the user-supplied value of xcomp_bv is 0 > in > the uncompacted case, and returning an error otherwise. > Reviewed-by: Rik van Riel <r...@

Re: [kernel-hardening] [PATCH v3 1/3] x86/fpu: don't let userspace set bogus xcomp_bv

On Thu, 2017-09-21 at 11:52 -0700, Eric Biggers wrote: > From: Eric Biggers > > Fix the bug by checking that the user-supplied value of xcomp_bv is 0 > in > the uncompacted case, and returning an error otherwise. > Reviewed-by: Rik van Riel -- All rights reversed signatu

Re: [patch v2] madvise.2: Add MADV_WIPEONFORK documentation

On Tue, 2017-09-19 at 21:07 +0200, Michael Kerrisk (man-pages) wrote: > Thanks. I applied this, and tweaked the madvise.2 text a little, to > read as follows (please let me know if I messed anything up): > >    MADV_WIPEONFORK (since Linux 4.14) >   Present the child process with

Re: [patch v2] madvise.2: Add MADV_WIPEONFORK documentation

On Tue, 2017-09-19 at 21:07 +0200, Michael Kerrisk (man-pages) wrote: > Thanks. I applied this, and tweaked the madvise.2 text a little, to > read as follows (please let me know if I messed anything up): > >    MADV_WIPEONFORK (since Linux 4.14) >   Present the child process with

Re: [PATCH] mm: Fix typo in VM_MPX definition

df3735c5b40f ("x86,mpx: make mpx depend on x86-64 to free up > VMA flag") > Cc: Rik van Riel <r...@redhat.com> > Cc: Dave Hansen <dave.han...@intel.com> Reviewed-by: Rik van Riel <r...@redhat.com>

Re: [PATCH] mm: Fix typo in VM_MPX definition

depend on x86-64 to free up > VMA flag") > Cc: Rik van Riel > Cc: Dave Hansen Reviewed-by: Rik van Riel

[patch v2] madvise.2: Add MADV_WIPEONFORK documentation

: Rik van Riel <r...@redhat.com> Date: Wed Sep 6 16:25:15 2017 -0700 mm,fork: introduce MADV_WIPEONFORK Signed-off-by: Rik van Riel <r...@redhat.com> Signed-off-by: Colm MacCárthaigh <c...@allcosts.net> diff --git a/man2/fork.2 b/man2/fork.2 index b5af58ca08c0..b11e750e3876

[patch v2] madvise.2: Add MADV_WIPEONFORK documentation

: Rik van Riel Date: Wed Sep 6 16:25:15 2017 -0700 mm,fork: introduce MADV_WIPEONFORK Signed-off-by: Rik van Riel Signed-off-by: Colm MacCárthaigh diff --git a/man2/fork.2 b/man2/fork.2 index b5af58ca08c0..b11e750e3876 100644 --- a/man2/fork.2 +++ b/man2/fork.2 @@ -140,6 +140,12 @@ Memory

[patch] madvise.2: Add MADV_WIPEONFORK documentation

for both in the ERRORS section. This patch documents the following kernel commit: commit d2cd9ede6e193dd7d88b6d27399e96229a551b19 Author: Rik van Riel <r...@redhat.com> Date: Wed Sep 6 16:25:15 2017 -0700 mm,fork: introduce MADV_WIPEONFORK Signed-off-by: Rik van Riel <r...@redhat.co

[patch] madvise.2: Add MADV_WIPEONFORK documentation

for both in the ERRORS section. This patch documents the following kernel commit: commit d2cd9ede6e193dd7d88b6d27399e96229a551b19 Author: Rik van Riel Date: Wed Sep 6 16:25:15 2017 -0700 mm,fork: introduce MADV_WIPEONFORK Signed-off-by: Rik van Riel index dfb31b63dba3..4f987ddfae79 100644

Re: [lkp-robot] [sched/fair] 6d46bd3d97: netperf.Throughput_tps -11.3% regression

On Sun, 2017-09-10 at 23:32 -0700, Joel Fernandes wrote: > > To make the load check more meaningful, I am thinking if using > wake_affine()'s balance check is a better thing to do than the > 'nr_running < 2' check I used in this patch. Then again, since commit > 3fed382b46baac ("sched/numa:

Re: [lkp-robot] [sched/fair] 6d46bd3d97: netperf.Throughput_tps -11.3% regression

On Sun, 2017-09-10 at 23:32 -0700, Joel Fernandes wrote: > > To make the load check more meaningful, I am thinking if using > wake_affine()'s balance check is a better thing to do than the > 'nr_running < 2' check I used in this patch. Then again, since commit > 3fed382b46baac ("sched/numa:

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On Sun, 2017-09-10 at 18:46 -0700, Andy Lutomirski wrote: > > No, nothing stops the problematic speculative load.  Here's the > issue. > One CPU removes a reference to a page table from a higher-level page > table, flushes, and then frees the page table.  Then it re-allocates > it and writes

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On Sun, 2017-09-10 at 18:46 -0700, Andy Lutomirski wrote: > > No, nothing stops the problematic speculative load.  Here's the > issue. > One CPU removes a reference to a page table from a higher-level page > table, flushes, and then frees the page table.  Then it re-allocates > it and writes

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On Sat, 2017-09-09 at 12:28 -0700, Andy Lutomirski wrote: > - > I propose the following fix.  If PCID is on, then, in > enter_lazy_tlb(), we switch to init_mm with the no-flush flag set. > (And we give init_mm its own dedicated ASID to keep it simple and > fast > -- no need to use the LRU ASID

Re: Current mainline git (24e700e291d52bd2) hangs when building e.g. perf

On Sat, 2017-09-09 at 12:28 -0700, Andy Lutomirski wrote: > - > I propose the following fix.  If PCID is on, then, in > enter_lazy_tlb(), we switch to init_mm with the no-flush flag set. > (And we give init_mm its own dedicated ASID to keep it simple and > fast > -- no need to use the LRU ASID

Re: [RFC 1/2] proc: Return if nothing to unmount

On Sat, 2017-09-09 at 19:31 +0100, Al Viro wrote: > On Sat, Sep 09, 2017 at 06:03:16PM +0530, Gargi Sharma wrote: > > If a task exits before procfs is mounted, proc_flush_task_mnt will > > be called with a NULL mnt parameter. In that case, not only is > > there > > nothing to unhash, but trying to

Re: [RFC 1/2] proc: Return if nothing to unmount

On Sat, 2017-09-09 at 19:31 +0100, Al Viro wrote: > On Sat, Sep 09, 2017 at 06:03:16PM +0530, Gargi Sharma wrote: > > If a task exits before procfs is mounted, proc_flush_task_mnt will > > be called with a NULL mnt parameter. In that case, not only is > > there > > nothing to unhash, but trying to

Re: [RFC 1/2] proc: Return if nothing to unmount

On September 9, 2017 2:31:35 PM EDT, Al Viro wrote: >On Sat, Sep 09, 2017 at 06:03:16PM +0530, Gargi Sharma wrote: >> If a task exits before procfs is mounted, proc_flush_task_mnt will >> be called with a NULL mnt parameter. In that case, not only is there >> nothing to

Re: [RFC 1/2] proc: Return if nothing to unmount

On September 9, 2017 2:31:35 PM EDT, Al Viro wrote: >On Sat, Sep 09, 2017 at 06:03:16PM +0530, Gargi Sharma wrote: >> If a task exits before procfs is mounted, proc_flush_task_mnt will >> be called with a NULL mnt parameter. In that case, not only is there >> nothing to unhash, but trying to do

Re: [RFC PATCH 01/12] housekeeping: Move housekeeping related code to its own file

On Wed, 2017-08-23 at 03:51 +0200, Frederic Weisbecker wrote: > The housekeeping code is currently tied to the nohz code. As we are > planning to make housekeeping independant from it, start with moving > the relevant code to its own file. > Why are nohz full and housekeeping being decoupled from

Re: [RFC PATCH 01/12] housekeeping: Move housekeeping related code to its own file

On Wed, 2017-08-23 at 03:51 +0200, Frederic Weisbecker wrote: > The housekeeping code is currently tied to the nohz code. As we are > planning to make housekeeping independant from it, start with moving > the relevant code to its own file. > Why are nohz full and housekeeping being decoupled from

Re: [kernel-hardening] [PATCH v2 24/30] fork: Define usercopy region in mm_struct slab caches

o userspace. > Acked-by: Rik van Riel <r...@redhat.com> -- All rights reversed signature.asc Description: This is a digitally signed message part

Re: [kernel-hardening] [PATCH v2 24/30] fork: Define usercopy region in mm_struct slab caches

On Mon, 2017-08-28 at 14:35 -0700, Kees Cook wrote: > From: David Windsor > > In support of usercopy hardening, this patch defines a region in the > mm_struct slab caches in which userspace copy operations are allowed. > Only the auxv field is copied to userspace. > Acke

Re: [kernel-hardening] [PATCH v2 25/30] fork: Define usercopy region in thread_stack slab caches

ck needs to be available to userspace, the > entire slab contents are whitelisted. Note that the slab-based thread > stack is only present on systems with THREAD_SIZE < PAGE_SIZE and > !CONFIG_VMAP_STACK. > Acked-by: Rik van Riel <r...@redhat.com> -- All rights reversed s

Re: [kernel-hardening] [PATCH v2 25/30] fork: Define usercopy region in thread_stack slab caches

lable to userspace, the > entire slab contents are whitelisted. Note that the slab-based thread > stack is only present on systems with THREAD_SIZE < PAGE_SIZE and > !CONFIG_VMAP_STACK. > Acked-by: Rik van Riel -- All rights reversed signature.asc Description: This is a digitally signed message part

Re: [kernel-hardening] [PATCH v2 27/30] x86: Implement thread_struct whitelist for hardened usercopy

> --- >  arch/x86/Kconfig | 1 + >  arch/x86/include/asm/processor.h | 8 >  2 files changed, 9 insertions(+) > Acked-by: Rik van Riel <r...@redhat.com> -- All rights reversed signature.asc Description: This is a digitally signed message part

Re: [kernel-hardening] [PATCH v2 27/30] x86: Implement thread_struct whitelist for hardened usercopy

Cc: x...@kernel.org > Cc: Borislav Petkov > Cc: Andy Lutomirski > Cc: Mathias Krause > Signed-off-by: Kees Cook > --- >  arch/x86/Kconfig | 1 + >  arch/x86/include/asm/processor.h | 8 ++++++++ >  2 files changed, 9 insertions(+) > Acked-by: Rik

Re: [kernel-hardening] [PATCH v2 26/30] fork: Provide usercopy whitelisting for task_struct

ion of task_struct that is potentially dynamically sized > and > may be copied to userspace is in the architecture-specific > thread_struct > at the end of task_struct. > Acked-by: Rik van Riel <r...@redhat.com> -- All rights reversed signature.asc Description: This is a digitally signed message part

Re: [kernel-hardening] [PATCH v2 26/30] fork: Provide usercopy whitelisting for task_struct

ion of task_struct that is potentially dynamically sized > and > may be copied to userspace is in the architecture-specific > thread_struct > at the end of task_struct. > Acked-by: Rik van Riel -- All rights reversed signature.asc Description: This is a digitally signed message part

Re: [PATCH 2/2] mm,fork: introduce MADV_WIPEONFORK

On Fri, 2017-08-18 at 11:15 -0700, Andrew Morton wrote: > On Fri, 18 Aug 2017 12:28:29 -0400 Rik van Riel <r...@redhat.com> > wrote: > > > On Thu, 2017-08-17 at 15:50 -0700, Andrew Morton wrote: > > > On Tue, 15 Aug 2017 22:18:19 -0400 Rik van Riel

Re: [PATCH 2/2] mm,fork: introduce MADV_WIPEONFORK

On Fri, 2017-08-18 at 11:15 -0700, Andrew Morton wrote: > On Fri, 18 Aug 2017 12:28:29 -0400 Rik van Riel > wrote: > > > On Thu, 2017-08-17 at 15:50 -0700, Andrew Morton wrote: > > > On Tue, 15 Aug 2017 22:18:19 -0400 Rik van Riel > > > wrote: >

Re: [PATCH 2/2] mm,fork: introduce MADV_WIPEONFORK

On Thu, 2017-08-17 at 15:50 -0700, Andrew Morton wrote: > On Tue, 15 Aug 2017 22:18:19 -0400 Rik van Riel <r...@redhat.com> > wrote: > > > > > --- a/mm/madvise.c > > > > +++ b/mm/madvise.c > > > > @@ -80,6 +80,17 @@ static long

Re: [PATCH 2/2] mm,fork: introduce MADV_WIPEONFORK

On Thu, 2017-08-17 at 15:50 -0700, Andrew Morton wrote: > On Tue, 15 Aug 2017 22:18:19 -0400 Rik van Riel > wrote: > > > > > --- a/mm/madvise.c > > > > +++ b/mm/madvise.c > > > > @@ -80,6 +80,17 @@ static long madvis

Re: [PATCH 2/2] mm,fork: introduce MADV_WIPEONFORK

On Tue, 2017-08-15 at 15:51 -0700, Andrew Morton wrote: > On Fri, 11 Aug 2017 17:28:29 -0400 r...@redhat.com wrote: > > > A further complication is the proliferation of clone flags, > > programs bypassing glibc's functions to call clone directly, > > and programs calling unshare, causing the

Re: [PATCH 2/2] mm,fork: introduce MADV_WIPEONFORK

On Tue, 2017-08-15 at 15:51 -0700, Andrew Morton wrote: > On Fri, 11 Aug 2017 17:28:29 -0400 r...@redhat.com wrote: > > > A further complication is the proliferation of clone flags, > > programs bypassing glibc's functions to call clone directly, > > and programs calling unshare, causing the

Re: [kernel-hardening] Re: x86: PIE support and option to extend KASLR randomization

On Tue, 2017-08-15 at 08:15 -0400, Jordan Glover wrote: > Hello, > I write to put different perspective into the topic. I'm glad that > kernel developers care about performance optimizations and I see how > 10% overhead can be a problem for some. On the other hand last ten > years gave us 1000%

Re: [kernel-hardening] Re: x86: PIE support and option to extend KASLR randomization

On Tue, 2017-08-15 at 08:15 -0400, Jordan Glover wrote: > Hello, > I write to put different perspective into the topic. I'm glad that > kernel developers care about performance optimizations and I see how > 10% overhead can be a problem for some. On the other hand last ten > years gave us 1000%

Re: [PATCH 2/2] mm,fork: introduce MADV_WIPEONFORK

On Fri, 2017-08-11 at 12:42 -0700, Linus Torvalds wrote: > On Fri, Aug 11, 2017 at 12:19 PM,   wrote: > > diff --git a/mm/memory.c b/mm/memory.c > > index 0e517be91a89..f9b0ad7feb57 100644 > > --- a/mm/memory.c > > +++ b/mm/memory.c > > @@ -1134,6 +1134,16 @@ int

Re: [PATCH 2/2] mm,fork: introduce MADV_WIPEONFORK

On Fri, 2017-08-11 at 12:42 -0700, Linus Torvalds wrote: > On Fri, Aug 11, 2017 at 12:19 PM,   wrote: > > diff --git a/mm/memory.c b/mm/memory.c > > index 0e517be91a89..f9b0ad7feb57 100644 > > --- a/mm/memory.c > > +++ b/mm/memory.c > > @@ -1134,6 +1134,16 @@ int copy_page_range(struct mm_struct >

Re: [PATCH 2/2] mm,fork: introduce MADV_WIPEONFORK

On Fri, 2017-08-11 at 09:36 -0700, Mike Kravetz wrote: > On 08/11/2017 08:23 AM, Rik van Riel wrote: > > On Thu, 2017-08-10 at 17:23 +0200, Michal Hocko wrote: > > > On Sun 06-08-17 10:04:25, Rik van Riel wrote: > > > [...] > > > > diff --git a/kern

Re: [PATCH 2/2] mm,fork: introduce MADV_WIPEONFORK

On Fri, 2017-08-11 at 09:36 -0700, Mike Kravetz wrote: > On 08/11/2017 08:23 AM, Rik van Riel wrote: > > On Thu, 2017-08-10 at 17:23 +0200, Michal Hocko wrote: > > > On Sun 06-08-17 10:04:25, Rik van Riel wrote: > > > [...] > > > > diff --git a/kern

Re: [PATCH 2/2] mm,fork: introduce MADV_WIPEONFORK

On Thu, 2017-08-10 at 17:23 +0200, Michal Hocko wrote: > On Sun 06-08-17 10:04:25, Rik van Riel wrote: > [...] > > diff --git a/kernel/fork.c b/kernel/fork.c > > index 17921b0390b4..db1fb2802ecc 100644 > > --- a/kernel/fork.c > > +++ b/kernel/fork.c > > @@ -659,

Re: [PATCH 2/2] mm,fork: introduce MADV_WIPEONFORK

On Thu, 2017-08-10 at 17:23 +0200, Michal Hocko wrote: > On Sun 06-08-17 10:04:25, Rik van Riel wrote: > [...] > > diff --git a/kernel/fork.c b/kernel/fork.c > > index 17921b0390b4..db1fb2802ecc 100644 > > --- a/kernel/fork.c > > +++ b/kernel/fork.c > > @@ -659,

[tip:sched/core] sched/numa: Slow down scan rate if shared faults dominate

Commit-ID: 37ec97deb3a8c68a7adfab61beb261ffeab19d09 Gitweb: http://git.kernel.org/tip/37ec97deb3a8c68a7adfab61beb261ffeab19d09 Author: Rik van Riel <r...@redhat.com> AuthorDate: Mon, 31 Jul 2017 15:28:46 -0400 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Thu, 10 Au

[tip:sched/core] sched/numa: Slow down scan rate if shared faults dominate

Commit-ID: 37ec97deb3a8c68a7adfab61beb261ffeab19d09 Gitweb: http://git.kernel.org/tip/37ec97deb3a8c68a7adfab61beb261ffeab19d09 Author: Rik van Riel AuthorDate: Mon, 31 Jul 2017 15:28:46 -0400 Committer: Ingo Molnar CommitDate: Thu, 10 Aug 2017 12:18:16 +0200 sched/numa: Slow down scan

[tip:sched/core] sched/numa: Scale scan period with tasks in group and shared/private

Commit-ID: b5dd77c8bdada7b6262d0cba02a6ed525bf4e6e1 Gitweb: http://git.kernel.org/tip/b5dd77c8bdada7b6262d0cba02a6ed525bf4e6e1 Author: Rik van Riel <r...@redhat.com> AuthorDate: Mon, 31 Jul 2017 15:28:47 -0400 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Thu, 10 Au

[tip:sched/core] sched/numa: Scale scan period with tasks in group and shared/private

Commit-ID: b5dd77c8bdada7b6262d0cba02a6ed525bf4e6e1 Gitweb: http://git.kernel.org/tip/b5dd77c8bdada7b6262d0cba02a6ed525bf4e6e1 Author: Rik van Riel AuthorDate: Mon, 31 Jul 2017 15:28:47 -0400 Committer: Ingo Molnar CommitDate: Thu, 10 Aug 2017 12:18:16 +0200 sched/numa: Scale scan

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Wed, 2017-08-09 at 12:59 +0300, Kirill A. Shutemov wrote: > On Mon, Aug 07, 2017 at 10:59:51AM -0400, Rik van Riel wrote: > > On Mon, 2017-08-07 at 15:46 +0200, Michal Hocko wrote: > > > On Mon 07-08-17 15:22:57, Michal Hocko wrote: > > > > This is an user visible

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Wed, 2017-08-09 at 12:59 +0300, Kirill A. Shutemov wrote: > On Mon, Aug 07, 2017 at 10:59:51AM -0400, Rik van Riel wrote: > > On Mon, 2017-08-07 at 15:46 +0200, Michal Hocko wrote: > > > On Mon 07-08-17 15:22:57, Michal Hocko wrote: > > > > This is an user visible

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Tue, 2017-08-08 at 09:52 -0700, Matthew Wilcox wrote: > On Tue, Aug 08, 2017 at 11:46:08AM -0400, Rik van Riel wrote: > > On Tue, 2017-08-08 at 08:19 -0700, Mike Kravetz wrote: > > > If the use case is fairly specific, then perhaps it makes sense > > > to

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Tue, 2017-08-08 at 09:52 -0700, Matthew Wilcox wrote: > On Tue, Aug 08, 2017 at 11:46:08AM -0400, Rik van Riel wrote: > > On Tue, 2017-08-08 at 08:19 -0700, Mike Kravetz wrote: > > > If the use case is fairly specific, then perhaps it makes sense > > > to

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Tue, 2017-08-08 at 08:19 -0700, Mike Kravetz wrote: > The other question I was trying to bring up is "What does > MADV_WIPEONFORK > mean for various types of mappings?"  For example, if we allow > MADV_WIPEONFORK on a file backed mapping what does that mapping look > like in the child after

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Tue, 2017-08-08 at 08:19 -0700, Mike Kravetz wrote: > The other question I was trying to bring up is "What does > MADV_WIPEONFORK > mean for various types of mappings?"  For example, if we allow > MADV_WIPEONFORK on a file backed mapping what does that mapping look > like in the child after

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Tue, 2017-08-08 at 11:58 +0200, Florian Weimer wrote: > On 08/07/2017 08:23 PM, Mike Kravetz wrote: > > If my thoughts above are correct, what about returning EINVAL if > > one > > attempts to set MADV_DONTFORK on mappings set up for sharing? > > That's my preference as well.  If there is a

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Tue, 2017-08-08 at 11:58 +0200, Florian Weimer wrote: > On 08/07/2017 08:23 PM, Mike Kravetz wrote: > > If my thoughts above are correct, what about returning EINVAL if > > one > > attempts to set MADV_DONTFORK on mappings set up for sharing? > > That's my preference as well.  If there is a

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Mon, 2017-08-07 at 15:46 +0200, Michal Hocko wrote: > On Mon 07-08-17 15:22:57, Michal Hocko wrote: > > This is an user visible API so make sure you CC linux-api (added) > > > > On Sun 06-08-17 10:04:23, Rik van Riel wrote: > > > > > > A further com

Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Mon, 2017-08-07 at 15:46 +0200, Michal Hocko wrote: > On Mon 07-08-17 15:22:57, Michal Hocko wrote: > > This is an user visible API so make sure you CC linux-api (added) > > > > On Sun 06-08-17 10:04:23, Rik van Riel wrote: > > > > > > A further com

Re: [PATCH 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Sat, 2017-08-05 at 02:44 +0300, Kirill A. Shutemov wrote: > On Fri, Aug 04, 2017 at 03:07:28PM -0400, r...@redhat.com wrote: > > [resend because half the recipients got dropped due to IPv6 > > firewall issues] > > > > Introduce MADV_WIPEONFORK semantics, which result in a VMA being > > empty

Re: [PATCH 0/2] mm,fork,security: introduce MADV_WIPEONFORK

On Sat, 2017-08-05 at 02:44 +0300, Kirill A. Shutemov wrote: > On Fri, Aug 04, 2017 at 03:07:28PM -0400, r...@redhat.com wrote: > > [resend because half the recipients got dropped due to IPv6 > > firewall issues] > > > > Introduce MADV_WIPEONFORK semantics, which result in a VMA being > > empty

Re: [PATCH 2/2] mm,fork: introduce MADV_WIPEONFORK

On Fri, 2017-08-04 at 16:09 -0700, Mike Kravetz wrote: > On 08/04/2017 12:07 PM, r...@redhat.com wrote: > > From: Rik van Riel <r...@redhat.com> > > > > Introduce MADV_WIPEONFORK semantics, which result in a VMA being > > empty in the child process after fork. Th

Re: [PATCH 2/2] mm,fork: introduce MADV_WIPEONFORK

On Fri, 2017-08-04 at 16:09 -0700, Mike Kravetz wrote: > On 08/04/2017 12:07 PM, r...@redhat.com wrote: > > From: Rik van Riel > > > > Introduce MADV_WIPEONFORK semantics, which result in a VMA being > > empty in the child process after fork. This differs from &

Re: [PATCH -mm -v3 1/6] mm, swap: Add swap cache statistics sysfs interface

On Tue, 2017-07-25 at 09:51 +0800, Huang, Ying wrote: > From: Huang Ying > > The swap cache stats could be gotten only via sysrq, which isn't > convenient in some situation.  So the sysfs interface of swap cache > stats is added for that.  The added sysfs directories/files

Re: [PATCH -mm -v3 1/6] mm, swap: Add swap cache statistics sysfs interface

On Tue, 2017-07-25 at 09:51 +0800, Huang, Ying wrote: > From: Huang Ying > > The swap cache stats could be gotten only via sysrq, which isn't > convenient in some situation.  So the sysfs interface of swap cache > stats is added for that.  The added sysfs directories/files are as > follow, > >

Re: [PATCH -mm -v3 02/12] mm, THP, swap: Support to reclaim swap space for THP swapped out

So that, the normal pages > inside THP can be swapped in individually. > > Signed-off-by: "Huang, Ying" <ying.hu...@intel.com> > Cc: Johannes Weiner <han...@cmpxchg.org> > Cc: Minchan Kim <minc...@kernel.org> > Cc: Hugh Dickins <hu...@google.com> >

Re: [PATCH -mm -v3 02/12] mm, THP, swap: Support to reclaim swap space for THP swapped out

ide THP can be swapped in individually. > > Signed-off-by: "Huang, Ying" > Cc: Johannes Weiner > Cc: Minchan Kim > Cc: Hugh Dickins > Cc: Shaohua Li > Cc: Rik van Riel > Acked-by: Rik van Riel -- All rights reversed signature.asc Description: This is a digitally signed message part

Re: [PATCH -mm -v3 01/12] mm, THP, swap: Support to clear swap cache flag for THP swapped out

l.com> > Cc: Johannes Weiner <han...@cmpxchg.org> > Cc: Minchan Kim <minc...@kernel.org> > Cc: Hugh Dickins <hu...@google.com> > Cc: Shaohua Li <s...@kernel.org> > Cc: Rik van Riel <r...@redhat.com> > Acked-by: Rik van Riel <r...@redhat.com> -- All rights reversed signature.asc Description: This is a digitally signed message part

Re: [PATCH -mm -v3 01/12] mm, THP, swap: Support to clear swap cache flag for THP swapped out

> after clearing the swap cache flag, the swap cluster backing the THP > swapped out will be split.  So that the swap slots in the swap > cluster > can be swapped in as normal pages later. > > Signed-off-by: "Huang, Ying" > Cc: Johannes Weiner > Cc: Minchan Ki

Re: [RFC][PATCH] exec: Use init rlimits for setuid exec

On Mon, 2017-07-10 at 20:16 +0200, Michal Hocko wrote: > OK, I misread the code. 32b applications on 64b systems do top down > by > default and only if they override this by ADDR_COMPAT_LAYOUT > personality. For some reason I thought that 32b userspace goes a > different path and makes sure that

Re: [RFC][PATCH] exec: Use init rlimits for setuid exec

On Mon, 2017-07-10 at 20:16 +0200, Michal Hocko wrote: > OK, I misread the code. 32b applications on 64b systems do top down > by > default and only if they override this by ADDR_COMPAT_LAYOUT > personality. For some reason I thought that 32b userspace goes a > different path and makes sure that

Re: [PATCH] mm, vmscan: do not loop on too_many_isolated for ever

e it usually required a really insane workload to > trigger. But it seems that the issue can be reproduced also without > having an insane number of competing threads [3]. My worries stand, but lets fix the real observed bug, and not worry too much about the theoretical bug for now. Acked-b

Re: [PATCH] mm, vmscan: do not loop on too_many_isolated for ever

e it usually required a really insane workload to > trigger. But it seems that the issue can be reproduced also without > having an insane number of competing threads [3]. My worries stand, but lets fix the real observed bug, and not worry too much about the theoretical bug for now. Acked-by: Rik van Riel

Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Thu, 2017-07-06 at 10:55 -0500, Christoph Lameter wrote: > On Thu, 6 Jul 2017, Kees Cook wrote: > > > On Thu, Jul 6, 2017 at 6:43 AM, Christoph Lameter > > wrote: > > > On Wed, 5 Jul 2017, Kees Cook wrote: > > > > > > > @@ -3536,6 +3565,9 @@ static int kmem_cache_open(struct

Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Thu, 2017-07-06 at 10:55 -0500, Christoph Lameter wrote: > On Thu, 6 Jul 2017, Kees Cook wrote: > > > On Thu, Jul 6, 2017 at 6:43 AM, Christoph Lameter > > wrote: > > > On Wed, 5 Jul 2017, Kees Cook wrote: > > > > > > > @@ -3536,6 +3565,9 @@ static int kmem_cache_open(struct > > > >

Re: [tip:sched/core] sched/cputime: Refactor the cputime_adjust() code

On Fri, 2017-06-30 at 06:10 -0700, tip-bot for Gustavo A. R. Silva wrote: > +++ b/kernel/sched/cputime.c > @@ -615,19 +615,13 @@ static void cputime_adjust(struct task_cputime > *curr, >    * userspace. Once a task gets some ticks, the monotonicy > code at >    * 'update' will ensure

Re: [tip:sched/core] sched/cputime: Refactor the cputime_adjust() code

On Fri, 2017-06-30 at 06:10 -0700, tip-bot for Gustavo A. R. Silva wrote: > +++ b/kernel/sched/cputime.c > @@ -615,19 +615,13 @@ static void cputime_adjust(struct task_cputime > *curr, >    * userspace. Once a task gets some ticks, the monotonicy > code at >    * 'update' will ensure

Re: [PATCH 5/5] sched: Accumulate vtime on top of nsec clocksource

accounting), > harmonize clock sources] > > Reported-by: Luiz Capitulino <lcapitul...@redhat.com> > Suggested-by: Thomas Gleixner <t...@linutronix.de> > Not-Yet-Signed-off-by: Wanpeng Li <kernel...@gmail.com> > Cc: Rik van Riel <r...@redhat.com> > Cc: Peter

Re: [PATCH 5/5] sched: Accumulate vtime on top of nsec clocksource

ources] > > Reported-by: Luiz Capitulino > Suggested-by: Thomas Gleixner > Not-Yet-Signed-off-by: Wanpeng Li > Cc: Rik van Riel > Cc: Peter Zijlstra > Cc: Thomas Gleixner > Cc: Wanpeng Li > Cc: Ingo Molnar > Cc: Luiz Capitulino > Signed-off-by: Frederic Weisbecker Acked-by: Rik van Riel

Re: [PATCH 4/5] sched: Move vtime task fields to their own struct

On Thu, 2017-06-29 at 19:15 +0200, Frederic Weisbecker wrote: > We are about to add vtime accumulation fields to the task struct. > Let's > avoid more bloatification and gather vtime informations to their own > struct. > > Cc: Wanpeng Li <kernel...@gmail.com> > Cc: Ri

Re: [PATCH 4/5] sched: Move vtime task fields to their own struct

On Thu, 2017-06-29 at 19:15 +0200, Frederic Weisbecker wrote: > We are about to add vtime accumulation fields to the task struct. > Let's > avoid more bloatification and gather vtime informations to their own > struct. > > Cc: Wanpeng Li > Cc: Rik van Riel > Cc: Pete

Re: [PATCH 3/5] sched: Rename vtime fields

to run a > basic > state machine that tracks down cputime entry while switching between > contexts. > > So lets reflect that with more meaningful names. > > Cc: Wanpeng Li <kernel...@gmail.com> > Cc: Rik van Riel <r...@redhat.com> > Cc: Peter Zijlstra <pe

Re: [PATCH 3/5] sched: Rename vtime fields

to run a > basic > state machine that tracks down cputime entry while switching between > contexts. > > So lets reflect that with more meaningful names. > > Cc: Wanpeng Li > Cc: Rik van Riel > Cc: Peter Zijlstra > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc:

Re: [PATCH 2/5] sched: Always set vtime_snap_whence after accounting vtime

t; vtime_user_exit() is the only function that doesn't follow that rule > and that can bug the reviewer for a little while until he realizes > there > is no reason for this special case. > > Cc: Wanpeng Li <kernel...@gmail.com> > Cc: Rik van Riel <r...@redhat.com>

Re: [PATCH 2/5] sched: Always set vtime_snap_whence after accounting vtime

t; vtime_user_exit() is the only function that doesn't follow that rule > and that can bug the reviewer for a little while until he realizes > there > is no reason for this special case. > > Cc: Wanpeng Li > Cc: Rik van Riel > Cc: Peter Zijlstra > Cc: Thomas Gleixner

Re: [PATCH 1/5] vtime: Remove vtime_account_user()

On Thu, 2017-06-29 at 19:15 +0200, Frederic Weisbecker wrote: > It's an unnecessary function between vtime_user_exit() and > account_user_time(). > > Cc: Wanpeng Li <kernel...@gmail.com> > Cc: Rik van Riel <r...@redhat.com> > Cc: Peter Zijlstra <pet...@infrad

Re: [PATCH 1/5] vtime: Remove vtime_account_user()

On Thu, 2017-06-29 at 19:15 +0200, Frederic Weisbecker wrote: > It's an unnecessary function between vtime_user_exit() and > account_user_time(). > > Cc: Wanpeng Li > Cc: Rik van Riel > Cc: Peter Zijlstra > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: Lu

Re: [PATCH v2] mm: Add SLUB free list pointer obfuscation

On Thu, 2017-06-29 at 10:47 -0700, Kees Cook wrote: > On Thu, Jun 29, 2017 at 10:05 AM, Christoph Lameter > wrote: > > On Sun, 25 Jun 2017, Kees Cook wrote: > > > > > The difference gets lost in the noise, but if the above is > > > sensible, > > > it's 0.07% slower. ;) > > > >

Re: [PATCH v2] mm: Add SLUB free list pointer obfuscation

On Thu, 2017-06-29 at 10:47 -0700, Kees Cook wrote: > On Thu, Jun 29, 2017 at 10:05 AM, Christoph Lameter > wrote: > > On Sun, 25 Jun 2017, Kees Cook wrote: > > > > > The difference gets lost in the noise, but if the above is > > > sensible, > > > it's 0.07% slower. ;) > > > > Hmmm... These

Re: [PATCH] sched/numa: fix build without CONFIG_NUMA_BALANCING

On Wed, 2017-06-28 at 22:05 +0200, Arnd Bergmann wrote: > I ran into a build error: > > kernel/sched/fair.c:2655:44: error: 'struct sched_domain' declared > inside parameter list will not be visible outside of this definition > or declaration [-Werror] > > Adding a forward declaration for the

Re: [PATCH] sched/numa: fix build without CONFIG_NUMA_BALANCING

On Wed, 2017-06-28 at 22:05 +0200, Arnd Bergmann wrote: > I ran into a build error: > > kernel/sched/fair.c:2655:44: error: 'struct sched_domain' declared > inside parameter list will not be visible outside of this definition > or declaration [-Werror] > > Adding a forward declaration for the

Re: [PATCH 4/4] sched,fair: remove effective_load

On Mon, 2017-06-26 at 18:12 +0200, Peter Zijlstra wrote: > Also note that your use of task_h_load() in the new numa thing > suffers > from exactly the problem effective_load() is trying to solve. Thinking about this some more, I suspect that using effective_load() in combination with

Re: [PATCH 4/4] sched,fair: remove effective_load

On Mon, 2017-06-26 at 18:12 +0200, Peter Zijlstra wrote: > Also note that your use of task_h_load() in the new numa thing > suffers > from exactly the problem effective_load() is trying to solve. Thinking about this some more, I suspect that using effective_load() in combination with

<    4   5   6   7   8   9   10   11   12   13   >