Re: [v3 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On Tue, Apr 10, 2018 at 12:33:35PM -0700, Yang Shi wrote: ... > > The race condition is just valid when protecting start_brk, brk, start_data > and end_data with the new lock, but keep using mmap_sem in brk path. > > So, we should just need make a little tweak to have mmap_sem protect >

Re: [v3 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On Tue, Apr 10, 2018 at 11:28:13AM -0700, Yang Shi wrote: > > > > At the first glance, it looks feasible to me. Will look into deeper > > later. > > A further look told me this might be *not* feasible. > > It looks the new lock will not break check_data_rlimit since in my patch > both start_brk

Re: [v3 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On Tue, Apr 10, 2018 at 11:28:13AM -0700, Yang Shi wrote: > > > > At the first glance, it looks feasible to me. Will look into deeper > > later. > > A further look told me this might be *not* feasible. > > It looks the new lock will not break check_data_rlimit since in my patch > both start_brk

Re: [v3 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On Tue, Apr 10, 2018 at 01:10:01PM +0200, Michal Hocko wrote: > > > > Because do_brk does vma manipulations, for this reason it's > > running under down_write_killable(>mmap_sem). Or you > > mean something else? > > Yes, all we need the new lock for is to get a consistent view on brk > values. I

Re: [v3 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On Tue, Apr 10, 2018 at 01:10:01PM +0200, Michal Hocko wrote: > > > > Because do_brk does vma manipulations, for this reason it's > > running under down_write_killable(>mmap_sem). Or you > > mean something else? > > Yes, all we need the new lock for is to get a consistent view on brk > values. I

Re: [v3 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On Tue, Apr 10, 2018 at 12:42:15PM +0200, Michal Hocko wrote: > On Tue 10-04-18 12:40:47, Cyrill Gorcunov wrote: > > On Tue, Apr 10, 2018 at 11:09:17AM +0200, Michal Hocko wrote: > > > On Tue 10-04-18 05:52:54, Yang Shi wrote: > > > [...] > > > > So

Re: [v3 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On Tue, Apr 10, 2018 at 12:42:15PM +0200, Michal Hocko wrote: > On Tue 10-04-18 12:40:47, Cyrill Gorcunov wrote: > > On Tue, Apr 10, 2018 at 11:09:17AM +0200, Michal Hocko wrote: > > > On Tue 10-04-18 05:52:54, Yang Shi wrote: > > > [...] > > > > So

Re: [v3 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On Tue, Apr 10, 2018 at 11:09:17AM +0200, Michal Hocko wrote: > On Tue 10-04-18 05:52:54, Yang Shi wrote: > [...] > > So, introduce a new spinlock in mm_struct to protect the concurrent > > access to arg_start|end, env_start|end and others except start_brk and > > brk, which are still protected by

Re: [v3 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On Tue, Apr 10, 2018 at 11:09:17AM +0200, Michal Hocko wrote: > On Tue 10-04-18 05:52:54, Yang Shi wrote: > [...] > > So, introduce a new spinlock in mm_struct to protect the concurrent > > access to arg_start|end, env_start|end and others except start_brk and > > brk, which are still protected by

Re: [v3 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

sue will be solved in the > future. > > Signed-off-by: Yang Shi <yang@linux.alibaba.com> > Cc: Alexey Dobriyan <adobri...@gmail.com> > Cc: Michal Hocko <mho...@kernel.org> > Cc: Matthew Wilcox <wi...@infradead.org> > Cc: Mateusz Guzik <mgu...@redha

Re: [v3 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

ssue will be solved in the > future. > > Signed-off-by: Yang Shi > Cc: Alexey Dobriyan > Cc: Michal Hocko > Cc: Matthew Wilcox > Cc: Mateusz Guzik > Cc: Cyrill Gorcunov > --- > v2 --> v3: > * Restored down_write in prctl syscall > * Elaborate the limi

Re: [PATCH v2] prctl: Deprecate non PR_SET_MM_MAP operations

On Thu, Apr 05, 2018 at 08:56:50PM +0200, Michal Hocko wrote: > On Thu 05-04-18 21:26:51, Cyrill Gorcunov wrote: > > An ability to manipulate mm_struct fields was introduced in > > sake of CRIU in first place. Later we provide more suitable > > and safe operation PR_SET_MM

Re: [PATCH v2] prctl: Deprecate non PR_SET_MM_MAP operations

On Thu, Apr 05, 2018 at 08:56:50PM +0200, Michal Hocko wrote: > On Thu 05-04-18 21:26:51, Cyrill Gorcunov wrote: > > An ability to manipulate mm_struct fields was introduced in > > sake of CRIU in first place. Later we provide more suitable > > and safe operation PR_SET_MM

[PATCH v2] prctl: Deprecate non PR_SET_MM_MAP operations

ava...@openvz.org> CC: Andrew Morton <a...@linuxfoundation.org> CC: Pavel Emelyanov <xe...@virtuozzo.com> CC: Michael Kerrisk <mtk.manpa...@gmail.com> CC: Yang Shi <yang@linux.alibaba.com> CC: Michal Hocko <mho...@kernel.org> Signed-off-by: Cyrill Gorcunov &l

[PATCH v2] prctl: Deprecate non PR_SET_MM_MAP operations

: Andrew Morton CC: Pavel Emelyanov CC: Michael Kerrisk CC: Yang Shi CC: Michal Hocko Signed-off-by: Cyrill Gorcunov --- kernel/sys.c | 151 --- 1 file changed, 2 insertions(+), 149 deletions(-) Index: linux-ml.git/kernel/sys.c

Re: [PATCH] prctl: Deprecate non PR_SET_MM_MAP operations

On Wed, Apr 04, 2018 at 02:36:55PM -0700, Randy Dunlap wrote: > > > > So, maybe just get rid of any warning message at all? > > That would be OK since -EINVAL or something similar is being returned. Thanks for feedback! Will do tomorrow and send it out.

Re: [PATCH] prctl: Deprecate non PR_SET_MM_MAP operations

On Wed, Apr 04, 2018 at 02:36:55PM -0700, Randy Dunlap wrote: > > > > So, maybe just get rid of any warning message at all? > > That would be OK since -EINVAL or something similar is being returned. Thanks for feedback! Will do tomorrow and send it out.

Re: [PATCH] prctl: Deprecate non PR_SET_MM_MAP operations

On Wed, Apr 04, 2018 at 01:53:08PM -0700, Randy Dunlap wrote: > > > > At first this was plain warning without code removal but I've > > been advised that dropping it completely may be a better idea > > which I agree https://lkml.org/lkml/2018/4/4/31 Or you mean the > > warning message itsef? We

Re: [PATCH] prctl: Deprecate non PR_SET_MM_MAP operations

On Wed, Apr 04, 2018 at 01:53:08PM -0700, Randy Dunlap wrote: > > > > At first this was plain warning without code removal but I've > > been advised that dropping it completely may be a better idea > > which I agree https://lkml.org/lkml/2018/4/4/31 Or you mean the > > warning message itsef? We

Re: [PATCH] prctl: Deprecate non PR_SET_MM_MAP operations

On Wed, Apr 04, 2018 at 02:16:33PM -0700, Yang Shi wrote: > On 4/4/18 11:55 AM, Cyrill Gorcunov wrote: > > An ability to manipulate mm_struct fields was introduced in > > sake of CRIU in first place. Later we provide more suitable > > and safe operation PR_SET_MM_MAP where all

Re: [PATCH] prctl: Deprecate non PR_SET_MM_MAP operations

On Wed, Apr 04, 2018 at 02:16:33PM -0700, Yang Shi wrote: > On 4/4/18 11:55 AM, Cyrill Gorcunov wrote: > > An ability to manipulate mm_struct fields was introduced in > > sake of CRIU in first place. Later we provide more suitable > > and safe operation PR_SET_MM_MAP where all

Re: [PATCH] prctl: Deprecate non PR_SET_MM_MAP operations

On Wed, Apr 04, 2018 at 12:24:33PM -0700, Randy Dunlap wrote: > > > + pr_warn_once("Non PR_SET_MM_MAP operations are deprecated\n"); > > + return -EINVAL; > > } > > I'm not against removing such functionality, but I think that it's more than > "deprecated." It's gone. At first this was

Re: [PATCH] prctl: Deprecate non PR_SET_MM_MAP operations

On Wed, Apr 04, 2018 at 12:24:33PM -0700, Randy Dunlap wrote: > > > + pr_warn_once("Non PR_SET_MM_MAP operations are deprecated\n"); > > + return -EINVAL; > > } > > I'm not against removing such functionality, but I think that it's more than > "deprecated." It's gone. At first this was

[PATCH] prctl: Deprecate non PR_SET_MM_MAP operations

ation.org> CC: Pavel Emelyanov <xe...@virtuozzo.com> CC: Michael Kerrisk <mtk.manpa...@gmail.com> CC: Yang Shi <yang@linux.alibaba.com> CC: Michal Hocko <mho...@kernel.org> Signed-off-by: Cyrill Gorcunov <gorcu

[PATCH] prctl: Deprecate non PR_SET_MM_MAP operations

: Yang Shi CC: Michal Hocko Signed-off-by: Cyrill Gorcunov --- kernel/sys.c | 146 --- 1 file changed, 2 insertions(+), 144 deletions(-) Index: linux-ml.git/kernel/sys.c

Re: [RFC] prctl: Deprecate non PR_SET_MM_MAP operations

On Wed, Apr 04, 2018 at 08:54:59AM -0700, Yang Shi wrote: > > Yeah, let's just drop it and have the patch in linux-next (via mmotm) > > for 2 release cycles and see whether somebody complains. > > BTW, I will do my v3 on top of the patch (drop off prctl_set_mm). Sorry for delay, will do in a

Re: [RFC] prctl: Deprecate non PR_SET_MM_MAP operations

On Wed, Apr 04, 2018 at 08:54:59AM -0700, Yang Shi wrote: > > Yeah, let's just drop it and have the patch in linux-next (via mmotm) > > for 2 release cycles and see whether somebody complains. > > BTW, I will do my v3 on top of the patch (drop off prctl_set_mm). Sorry for delay, will do in a

Re: [RFC] prctl: Deprecate non PR_SET_MM_MAP operations

On Wed, Apr 04, 2018 at 07:35:41AM +0200, Michal Hocko wrote: > > > Or we can simply drop it off because PR_SET_MM_MAP covers all needs, > > > and I would rather prefer to do that asap. > > > > Thanks for making it deprecated. I'd prefer just drop it off if nobody > > objects. The change will get

Re: [RFC] prctl: Deprecate non PR_SET_MM_MAP operations

On Wed, Apr 04, 2018 at 07:35:41AM +0200, Michal Hocko wrote: > > > Or we can simply drop it off because PR_SET_MM_MAP covers all needs, > > > and I would rather prefer to do that asap. > > > > Thanks for making it deprecated. I'd prefer just drop it off if nobody > > objects. The change will get

[RFC] prctl: Deprecate non PR_SET_MM_MAP operations

Vagin <ava...@openvz.org> CC: Andrew Morton <a...@linuxfoundation.org> CC: Pavel Emelyanov <xe...@virtuozzo.com> CC: Michael Kerrisk <mtk.manpa...@gmail.com> CC: Yang Shi <yang@linux.alibaba.com> CC: Michal Hocko <mho...@kernel.org> Signed-off-by: Cyrill Gor

[RFC] prctl: Deprecate non PR_SET_MM_MAP operations

Vagin CC: Andrew Morton CC: Pavel Emelyanov CC: Michael Kerrisk CC: Yang Shi CC: Michal Hocko Signed-off-by: Cyrill Gorcunov --- Or we can simply drop it off because PR_SET_MM_MAP covers all needs, and I would rather prefer to do that asap. kernel/sys.c |2 ++ 1 file changed, 2

Re: [v2 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On Tue, Mar 27, 2018 at 02:38:11PM -0400, Yang Shi wrote: > > Why do we need to hold mmap_sem here and call find_vma, when only > > PR_SET_MM_ENV_END: is consuming it? I guess we can replace it wit the > > new lock and take the mmap_sem only for PR_SET_MM_ENV_END. > > Actually, I didn't think of

Re: [v2 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On Tue, Mar 27, 2018 at 02:38:11PM -0400, Yang Shi wrote: > > Why do we need to hold mmap_sem here and call find_vma, when only > > PR_SET_MM_ENV_END: is consuming it? I guess we can replace it wit the > > new lock and take the mmap_sem only for PR_SET_MM_ENV_END. > > Actually, I didn't think of

Re: [v2 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On Mon, Mar 26, 2018 at 06:12:55PM -0400, Yang Shi wrote: > > + if (unlikely(arg_start > arg_end || env_start > env_end)) { > > + cond_resched(); > > + goto retry; > > Can't it trap into dead loop if the condition is always false? Yes, unfortunately it can. > > + } > >

Re: [v2 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On Mon, Mar 26, 2018 at 06:12:55PM -0400, Yang Shi wrote: > > + if (unlikely(arg_start > arg_end || env_start > env_end)) { > > + cond_resched(); > > + goto retry; > > Can't it trap into dead loop if the condition is always false? Yes, unfortunately it can. > > + } > >

Re: [v2 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On Tue, Mar 27, 2018 at 07:00:56AM +0900, Tetsuo Handa wrote: > > > To be fair I would prefer to drop this old per-field > > interface completely. This per-field interface was rather an ugly > > solution from my side. > > But this is userspace visible API and thus we cannot change.

Re: [v2 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On Tue, Mar 27, 2018 at 07:00:56AM +0900, Tetsuo Handa wrote: > > > To be fair I would prefer to drop this old per-field > > interface completely. This per-field interface was rather an ugly > > solution from my side. > > But this is userspace visible API and thus we cannot change.

Re: [v2 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On Mon, Mar 26, 2018 at 05:59:49PM -0400, Yang Shi wrote: > > Say we've two syscalls running prctl_set_mm_map in parallel, and imagine > > one have @start_brk = 20 @brk = 10 and second caller has @start_brk = 30 > > and @brk = 20. Since now the call is guarded by _read_ the both calls > > unlocked

Re: [v2 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On Mon, Mar 26, 2018 at 05:59:49PM -0400, Yang Shi wrote: > > Say we've two syscalls running prctl_set_mm_map in parallel, and imagine > > one have @start_brk = 20 @brk = 10 and second caller has @start_brk = 30 > > and @brk = 20. Since now the call is guarded by _read_ the both calls > > unlocked

Re: [v2 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On Tue, Mar 27, 2018 at 06:10:09AM +0900, Tetsuo Handa wrote: > On 2018/03/27 4:21, Cyrill Gorcunov wrote: > > That said I think using read-lock here would be a bug. > > If I understand correctly, the caller can't set both fields atomically, for > prctl() does not receive both

Re: [v2 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On Tue, Mar 27, 2018 at 06:10:09AM +0900, Tetsuo Handa wrote: > On 2018/03/27 4:21, Cyrill Gorcunov wrote: > > That said I think using read-lock here would be a bug. > > If I understand correctly, the caller can't set both fields atomically, for > prctl() does not receive both

Re: [v2 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On Mon, Mar 26, 2018 at 11:37:25AM -0700, Matthew Wilcox wrote: > On Tue, Mar 27, 2018 at 02:20:39AM +0800, Yang Shi wrote: > > +++ b/kernel/sys.c > > @@ -1959,7 +1959,7 @@ static int prctl_set_mm_map(int opt, const void > > __user *addr, unsigned long data > > return error; >

Re: [v2 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On Mon, Mar 26, 2018 at 11:37:25AM -0700, Matthew Wilcox wrote: > On Tue, Mar 27, 2018 at 02:20:39AM +0800, Yang Shi wrote: > > +++ b/kernel/sys.c > > @@ -1959,7 +1959,7 @@ static int prctl_set_mm_map(int opt, const void > > __user *addr, unsigned long data > > return error; >

Re: [tip:x86/mm] x86/boot/compressed/64: Describe the logic behind the LA57 check

On Mon, Mar 12, 2018 at 03:32:12PM +0100, Ingo Molnar wrote: > > * Kirill A. Shutemov wrote: > > > > We can of course bike shed / benchmark this once my desktop refresh > > > sports this feature, but ISTR this being one of the very first things > > > Ingo mentioned when we

Re: [tip:x86/mm] x86/boot/compressed/64: Describe the logic behind the LA57 check

On Mon, Mar 12, 2018 at 03:32:12PM +0100, Ingo Molnar wrote: > > * Kirill A. Shutemov wrote: > > > > We can of course bike shed / benchmark this once my desktop refresh > > > sports this feature, but ISTR this being one of the very first things > > > Ingo mentioned when we started this whole 5L

Re: [PATCH v2] proc: fix /proc/*/map_files lookup some more

ey Dobriyan <adobri...@gmail.com> Reviewed-by: Cyrill Gorcunov <gorcu...@gmail.com>

Re: [PATCH v2] proc: fix /proc/*/map_files lookup some more

ib/systemd/systemd > > bogus > # readlink /proc/1/map_files/56427ecba000-56427eddc000 > /lib/systemd/systemd > # readlink /proc/1/map_files/56427ecba000-56427eddc000 > /lib/systemd/systemd > > Signed-off-by: Alexey Dobriyan Reviewed-by: Cyrill Gorcunov

Re: [tip:x86/boot] x86/boot/compressed/64: Prepare trampoline memory

On Mon, Feb 26, 2018 at 11:37:09AM +0300, Kirill A. Shutemov wrote: > On Mon, Feb 26, 2018 at 11:15:34AM +0300, Cyrill Gorcunov wrote: > > On Mon, Feb 26, 2018 at 11:02:56AM +0300, Kirill A. Shutemov wrote: > > ... > > > > Also, could do a puts() hexdump of the affec

Re: [tip:x86/boot] x86/boot/compressed/64: Prepare trampoline memory

On Mon, Feb 26, 2018 at 11:37:09AM +0300, Kirill A. Shutemov wrote: > On Mon, Feb 26, 2018 at 11:15:34AM +0300, Cyrill Gorcunov wrote: > > On Mon, Feb 26, 2018 at 11:02:56AM +0300, Kirill A. Shutemov wrote: > > ... > > > > Also, could do a puts() hexdump of the affec

Re: [tip:x86/boot] x86/boot/compressed/64: Prepare trampoline memory

On Mon, Feb 26, 2018 at 11:02:56AM +0300, Kirill A. Shutemov wrote: ... > > Also, could do a puts() hexdump of the affected memory area _before_ we > > overwrite > > it? Is it empty? Could we add some debug warning that checks that it's all > > zeroes? > > The problem is that we don't really

Re: [tip:x86/boot] x86/boot/compressed/64: Prepare trampoline memory

On Mon, Feb 26, 2018 at 11:02:56AM +0300, Kirill A. Shutemov wrote: ... > > Also, could do a puts() hexdump of the affected memory area _before_ we > > overwrite > > it? Is it empty? Could we add some debug warning that checks that it's all > > zeroes? > > The problem is that we don't really

Re: [PATCH v2] proc: fix /proc/*/map_files lookup some more

st place. The address priting is done via len = snprintf(buf, sizeof(buf), "%lx-%lx", p->start, p->end); > - how do we know that the first digit of a VMA address will never be 0? It should not be, due to snprintf above. --- Thanks a lot, Alexey! Reviewed-by: Cyrill Gorcunov <gorcu...@openvz.org>

Re: [PATCH v2] proc: fix /proc/*/map_files lookup some more

st place. The address priting is done via len = snprintf(buf, sizeof(buf), "%lx-%lx", p->start, p->end); > - how do we know that the first digit of a VMA address will never be 0? It should not be, due to snprintf above. --- Thanks a lot, Alexey! Reviewed-by: Cyrill Gorcunov

Re: [PATCH RFC v2 4/6] x86: Disable PTI on compatibility mode

On Thu, Feb 15, 2018 at 11:29:42PM +, Andy Lutomirski wrote: ... > >>> +bool pti_handle_segment_not_present(long error_code) > >>> +{ > >>> + if (!static_cpu_has(X86_FEATURE_PTI)) > >>> + return false; > >>> + > >>> + if ((unsigned short)error_code !=

Re: [PATCH RFC v2 4/6] x86: Disable PTI on compatibility mode

On Thu, Feb 15, 2018 at 11:29:42PM +, Andy Lutomirski wrote: ... > >>> +bool pti_handle_segment_not_present(long error_code) > >>> +{ > >>> + if (!static_cpu_has(X86_FEATURE_PTI)) > >>> + return false; > >>> + > >>> + if ((unsigned short)error_code !=

Re: [PATCH] x86/asm: Use PAGE_SIZE instead of 4096 where appropriate

On Wed, Feb 14, 2018 at 01:32:53PM +0300, Kirill A. Shutemov wrote: > Cyrill pointed that it makes sense to replace 4096 to PAGE_SIZE in > head_64.S. > > This patch replaces 4096 with PAGE_SIZE everywhere in assembly code > where it fits semantically. > > Suggested-by: C

Re: [PATCH] x86/asm: Use PAGE_SIZE instead of 4096 where appropriate

On Wed, Feb 14, 2018 at 01:32:53PM +0300, Kirill A. Shutemov wrote: > Cyrill pointed that it makes sense to replace 4096 to PAGE_SIZE in > head_64.S. > > This patch replaces 4096 with PAGE_SIZE everywhere in assembly code > where it fits semantically. > > Suggested-by: Cyri

Re: [tip:x86/boot] x86/boot/compressed/64: Prepare trampoline memory

On Sun, Feb 11, 2018 at 04:19:38AM -0800, tip-bot for Kirill A. Shutemov wrote: ... > diff --git a/arch/x86/boot/compressed/head_64.S > b/arch/x86/boot/compressed/head_64.S > index d598d65..af9ffbd 100644 > --- a/arch/x86/boot/compressed/head_64.S > +++ b/arch/x86/boot/compressed/head_64.S ... >

Re: [tip:x86/boot] x86/boot/compressed/64: Prepare trampoline memory

On Sun, Feb 11, 2018 at 04:19:38AM -0800, tip-bot for Kirill A. Shutemov wrote: ... > diff --git a/arch/x86/boot/compressed/head_64.S > b/arch/x86/boot/compressed/head_64.S > index d598d65..af9ffbd 100644 > --- a/arch/x86/boot/compressed/head_64.S > +++ b/arch/x86/boot/compressed/head_64.S ... >

Re: [PATCH] mm: Always print RLIMIT_DATA warning

On Tue, Feb 06, 2018 at 04:45:05PM +, David Woodhouse wrote: > The documentation for ignore_rlimit_data says that it will print a warning > at first misuse. Yet it doesn't seem to do that. Fix the code to print > the warning even when we allow the process to continue. > > Signed-off-by: David

Re: [PATCH] mm: Always print RLIMIT_DATA warning

On Tue, Feb 06, 2018 at 04:45:05PM +, David Woodhouse wrote: > The documentation for ignore_rlimit_data says that it will print a warning > at first misuse. Yet it doesn't seem to do that. Fix the code to print > the warning even when we allow the process to continue. > > Signed-off-by: David

Re: [PATCH] proc: delete children_seq_release()

On Wed, Nov 22, 2017 at 08:15:10PM +0300, Alexey Dobriyan wrote: > It is 1:1 wrapper around seq_release(). > > Signed-off-by: Alexey Dobriyan <adobri...@gmail.com> Acked-by: Cyrill Gorcunov <gorcu...@openvz.org> Thank you!

Re: [PATCH] proc: delete children_seq_release()

On Wed, Nov 22, 2017 at 08:15:10PM +0300, Alexey Dobriyan wrote: > It is 1:1 wrapper around seq_release(). > > Signed-off-by: Alexey Dobriyan Acked-by: Cyrill Gorcunov Thank you!

Re: [RFC] net/unix_diag: Provide UDIAG_SHOW_VFS2 attribute to fetch complete inode number

On Wed, Oct 25, 2017 at 09:55:07AM -0400, Roman Mashak wrote: > > I think __zero should be explicitly set to 0. It will be by compiler default.

Re: [RFC] net/unix_diag: Provide UDIAG_SHOW_VFS2 attribute to fetch complete inode number

On Wed, Oct 25, 2017 at 09:55:07AM -0400, Roman Mashak wrote: > > I think __zero should be explicitly set to 0. It will be by compiler default.

Re: [RFC] net/unix_diag: Provide UDIAG_SHOW_VFS2 attribute to fetch complete inode number

On Tue, Oct 24, 2017 at 05:25:16PM -0700, Andrei Vagin wrote: > On Wed, Oct 25, 2017 at 12:48:14AM +0300, Cyrill Gorcunov wrote: > > Currently unix_diag_vfs structure reports unix socket inode > > as u32 value which of course doesn't fit to ino_t type and > > BTW: A

Re: [RFC] net/unix_diag: Provide UDIAG_SHOW_VFS2 attribute to fetch complete inode number

On Tue, Oct 24, 2017 at 05:25:16PM -0700, Andrei Vagin wrote: > On Wed, Oct 25, 2017 at 12:48:14AM +0300, Cyrill Gorcunov wrote: > > Currently unix_diag_vfs structure reports unix socket inode > > as u32 value which of course doesn't fit to ino_t type and > > BTW: A

[RFC] net/unix_diag: Provide UDIAG_SHOW_VFS2 attribute to fetch complete inode number

ture). CC: Andrey Vagin <ava...@openvz.org> CC: David S. Miller <da...@davemloft.net> CC: Pavel Emelyanov <xe...@virtuozzo.com> Signed-off-by: Cyrill Gorcunov <gorcu...@openvz.org> --- I build-tested it only thus not for inclusion yet, but rather to discuss if there some b

[RFC] net/unix_diag: Provide UDIAG_SHOW_VFS2 attribute to fetch complete inode number

ture). CC: Andrey Vagin CC: David S. Miller CC: Pavel Emelyanov Signed-off-by: Cyrill Gorcunov --- I build-tested it only thus not for inclusion yet, but rather to discuss if there some better way to handle this potential problem. include/uapi/linux/unix_diag.h |8 net/u

[PATCH] kcmp: Drop branch leftover typo

The else branch been leftover and escaped the source code refresh. Not a problem but better clean it up. Reported-by: Eugene Syromiatnikov <e...@redhat.com> Signed-off-by: Cyrill Gorcunov <gorcu...@openvz.org> CC: Andrey Vagin <ava...@openvz.org> CC: Andrew Morton <a...@li

[PATCH] kcmp: Drop branch leftover typo

The else branch been leftover and escaped the source code refresh. Not a problem but better clean it up. Reported-by: Eugene Syromiatnikov Signed-off-by: Cyrill Gorcunov CC: Andrey Vagin CC: Andrew Morton CC: Pavel Emelyanov --- kernel/kcmp.c |2 +- 1 file changed, 1 insertion(+), 1

[PATCH] tools,selftest: kcmp -- Add KCMP_EPOLL_TFD testing

KCMP's KCMP_EPOLL_TFD mode merged in commit 0791e3644e5ef21646fe565b9061788d05ec71d4 but we've had no selftest for it yet (except in criu development list). Thus add it. Signed-off-by: Cyrill Gorcunov <gorcu...@openvz.org> CC: Andrey Vagin <ava...@openvz.org> CC: A

[PATCH] tools,selftest: kcmp -- Add KCMP_EPOLL_TFD testing

KCMP's KCMP_EPOLL_TFD mode merged in commit 0791e3644e5ef21646fe565b9061788d05ec71d4 but we've had no selftest for it yet (except in criu development list). Thus add it. Signed-off-by: Cyrill Gorcunov CC: Andrey Vagin CC: Andrew Morton CC: Pavel Emelyanov CC: Michael Kerrisk --- tools

Re: [PATCHv5 06/19] x86/boot/compressed/64: Detect and handle 5-level paging at boot-time

On Mon, Aug 21, 2017 at 06:29:03PM +0300, Kirill A. Shutemov wrote: > This patch prepare decompression code to boot-time switching between 4- > and 5-level paging. > > Signed-off-by: Kirill A. Shutemov > --- > arch/x86/boot/compressed/head_64.S | 24

Re: [PATCHv5 06/19] x86/boot/compressed/64: Detect and handle 5-level paging at boot-time

On Mon, Aug 21, 2017 at 06:29:03PM +0300, Kirill A. Shutemov wrote: > This patch prepare decompression code to boot-time switching between 4- > and 5-level paging. > > Signed-off-by: Kirill A. Shutemov > --- > arch/x86/boot/compressed/head_64.S | 24 > 1 file changed,

Re: [PATCH 1/2] x86: fix norandmaps

On Mon, Aug 14, 2017 at 06:43:10PM +0200, Oleg Nesterov wrote: > > Acked-by: Kirill A. Shutemov <kirill.shute...@linux.intel.com> > > OK, thanks Kirill and Cyrill, I'll resend tomorrow with all acks I got. I don't think you need my ack but if any Acked-by: Cyrill Gorcunov <gorcu...@openvz.org>

Re: [PATCH 1/2] x86: fix norandmaps

On Mon, Aug 14, 2017 at 06:43:10PM +0200, Oleg Nesterov wrote: > > Acked-by: Kirill A. Shutemov > > OK, thanks Kirill and Cyrill, I'll resend tomorrow with all acks I got. I don't think you need my ack but if any Acked-by: Cyrill Gorcunov

Re: [PATCH] x86/mm: Fix personality(ADDR_NO_RANDOMIZE)

On Mon, Aug 14, 2017 at 06:20:02PM +0200, Oleg Nesterov wrote: ... > > > > Didn't Oleg's patch does the same? > > > > https://patchwork.kernel.org/patch/9832697/ > > at first glance yes, thanks Cyrill. And note that we do not need another > PF_RANDOMIZE check. > > > for some reason it's not yet

Re: [PATCH] x86/mm: Fix personality(ADDR_NO_RANDOMIZE)

On Mon, Aug 14, 2017 at 06:20:02PM +0200, Oleg Nesterov wrote: ... > > > > Didn't Oleg's patch does the same? > > > > https://patchwork.kernel.org/patch/9832697/ > > at first glance yes, thanks Cyrill. And note that we do not need another > PF_RANDOMIZE check. > > > for some reason it's not yet

Re: [PATCH] x86/mm: Fix personality(ADDR_NO_RANDOMIZE)

On Mon, Aug 14, 2017 at 06:57:19PM +0300, Kirill A. Shutemov wrote: > In v4.12, during rework of infrastructure around mmap_base, disable-ASLR > personality flag got accidentally broken. > > Let's make it work again. > > Signed-off-by: Kirill A. Shutemov >

Re: [PATCH] x86/mm: Fix personality(ADDR_NO_RANDOMIZE)

On Mon, Aug 14, 2017 at 06:57:19PM +0300, Kirill A. Shutemov wrote: > In v4.12, during rework of infrastructure around mmap_base, disable-ASLR > personality flag got accidentally broken. > > Let's make it work again. > > Signed-off-by: Kirill A. Shutemov > Fixes: 1b028f784e8c ("x86/mm:

Re: [criu] 1M guard page ruined restore

On Thu, Jun 22, 2017 at 04:23:00PM +0200, Oleg Nesterov wrote: > Cyrill, > > I am replying to my own email because I got lost in numerous threads/emails > connected to stack guard/gap problems. IIRC you confirmed that the 1st load > doesn't fail and the patch fixes the problem. So everything is

Re: [criu] 1M guard page ruined restore

On Thu, Jun 22, 2017 at 04:23:00PM +0200, Oleg Nesterov wrote: > Cyrill, > > I am replying to my own email because I got lost in numerous threads/emails > connected to stack guard/gap problems. IIRC you confirmed that the 1st load > doesn't fail and the patch fixes the problem. So everything is

Re: [criu] 1M guard page ruined restore

On Wed, Jun 21, 2017 at 06:24:18PM -0700, Hugh Dickins wrote: > > > > At this moment, mmap() will no more return address one page lower > > and "guard" is no more a page: > > > > > MAP_GROWSDOWN > > >This flag is used for stacks. It indicates to the kernel virtual > > >memory

Re: [criu] 1M guard page ruined restore

On Wed, Jun 21, 2017 at 06:24:18PM -0700, Hugh Dickins wrote: > > > > At this moment, mmap() will no more return address one page lower > > and "guard" is no more a page: > > > > > MAP_GROWSDOWN > > >This flag is used for stacks. It indicates to the kernel virtual > > >memory

Re: [criu] 1M guard page ruined restore

On Wed, Jun 21, 2017 at 07:15:45PM +0200, Oleg Nesterov wrote: > On 06/21, Oleg Nesterov wrote: > > > > On 06/21, Cyrill Gorcunov wrote: > > > > > > On Wed, Jun 21, 2017 at 05:57:30PM +0200, Oleg Nesterov wrote: > > > > > > > >

Re: [criu] 1M guard page ruined restore

On Wed, Jun 21, 2017 at 07:15:45PM +0200, Oleg Nesterov wrote: > On 06/21, Oleg Nesterov wrote: > > > > On 06/21, Cyrill Gorcunov wrote: > > > > > > On Wed, Jun 21, 2017 at 05:57:30PM +0200, Oleg Nesterov wrote: > > > > > > > >

Re: [criu] 1M guard page ruined restore

On Wed, Jun 21, 2017 at 06:22:56PM +0300, Cyrill Gorcunov wrote: > This start failing because > > | static inline int check_stack_guard_page(struct vm_area_struct *vma, > unsigned long address) > > function get dropped off. Hugh, it is done on intent and > userspace pr

Re: [criu] 1M guard page ruined restore

On Wed, Jun 21, 2017 at 06:22:56PM +0300, Cyrill Gorcunov wrote: > This start failing because > > | static inline int check_stack_guard_page(struct vm_area_struct *vma, > unsigned long address) > > function get dropped off. Hugh, it is done on intent and > userspace pr

Re: [criu] 1M guard page ruined restore

On Wed, Jun 21, 2017 at 05:57:30PM +0200, Oleg Nesterov wrote: > (add Adrian) > > On 06/21, Cyrill Gorcunov wrote: > > > > The patches for criu are on the fly. Still one of the test case > > start failing with the new kernels. Basically the test does > > the fo

Re: [criu] 1M guard page ruined restore

On Wed, Jun 21, 2017 at 05:57:30PM +0200, Oleg Nesterov wrote: > (add Adrian) > > On 06/21, Cyrill Gorcunov wrote: > > > > The patches for criu are on the fly. Still one of the test case > > start failing with the new kernels. Basically the test does > > the fo

Re: [criu] 1M guard page ruined restore

On Tue, Jun 20, 2017 at 03:23:20AM -0700, Hugh Dickins wrote: ... > > We do need to understand this fairly quickly, since those stable > backports will pose more of a problem for you than the v4.12 > release itself. The patches for criu are on the fly. Still one of the test case start failing

Re: [criu] 1M guard page ruined restore

On Tue, Jun 20, 2017 at 03:23:20AM -0700, Hugh Dickins wrote: ... > > We do need to understand this fairly quickly, since those stable > backports will pose more of a problem for you than the v4.12 > release itself. The patches for criu are on the fly. Still one of the test case start failing

Re: [criu] 1M guard page ruined restore

On Tue, Jun 20, 2017 at 12:51:16PM +0200, Oleg Nesterov wrote: > > So I think you should simply disable, say, unmap_guard_pages() and most > of all other MAP_GROWSDOWN code in criu. I've sent out a series, lets see if it pass the tests.

Re: [criu] 1M guard page ruined restore

On Tue, Jun 20, 2017 at 12:51:16PM +0200, Oleg Nesterov wrote: > > So I think you should simply disable, say, unmap_guard_pages() and most > of all other MAP_GROWSDOWN code in criu. I've sent out a series, lets see if it pass the tests.

Re: [criu] 1M guard page ruined restore

On Tue, Jun 20, 2017 at 12:51:16PM +0200, Oleg Nesterov wrote: > > You can write a simple test. Just do mmap(MAP_GROWSDOWN) and look at > /proc/self/maps. If it reports vm_start + PAGE_SIZE rather than addr > returned by mmap, then the kernel is old. > > > Second I guess we might need to detect

Re: [criu] 1M guard page ruined restore

On Tue, Jun 20, 2017 at 12:51:16PM +0200, Oleg Nesterov wrote: > > You can write a simple test. Just do mmap(MAP_GROWSDOWN) and look at > /proc/self/maps. If it reports vm_start + PAGE_SIZE rather than addr > returned by mmap, then the kernel is old. > > > Second I guess we might need to detect

Re: [criu] 1M guard page ruined restore

On Tue, Jun 20, 2017 at 03:23:20AM -0700, Hugh Dickins wrote: > > Sorry for breaking you: we realized there was some risk of that. > > Would it be acceptable to you, to judge which kind of a kernel it is, > by whether it has a global variable stack_guard_gap? I don't know > if that would be a

Re: [criu] 1M guard page ruined restore

On Tue, Jun 20, 2017 at 03:23:20AM -0700, Hugh Dickins wrote: > > Sorry for breaking you: we realized there was some risk of that. > > Would it be acceptable to you, to judge which kind of a kernel it is, > by whether it has a global variable stack_guard_gap? I don't know > if that would be a

[criu] 1M guard page ruined restore

Hi Hugh! We're running our tests on latest vanilla kernel all the time, and recently we've got an issue on restore: https://github.com/xemul/criu/issues/322 | (00.410614) 4: cg: Cgroups 1 inherited from parent | (00.410858) 4: Opened local page read 3 (parent 0) | (00.410961)

<    1   2   3   4   5   6   7   8   9   10   >