Re: [PATCH] kconfig: remove EXPERT from CHECKPOINT_RESTORE

s the point of maintaining all of the complexity of > the ifdefs. If no one can come up with a reason I say let's just remove > CONFIG_CHECKPOINT_RESTORE entirely. > > Eric > > >> Signed-off-by: Adrian Reber >> Cc: Oleg Nesterov >> Cc: Pavel Emelyanov >

Re: [PATCH] kconfig: remove EXPERT from CHECKPOINT_RESTORE

s the point of maintaining all of the complexity of > the ifdefs. If no one can come up with a reason I say let's just remove > CONFIG_CHECKPOINT_RESTORE entirely. > > Eric > > >> Signed-off-by: Adrian Reber >> Cc: Oleg Nesterov >> Cc: Pavel Emelyanov >

Re: [PATCH] kconfig: remove EXPERT from CHECKPOINT_RESTORE

To make it easier for distributions to enable CHECKPOINT_RESTORE this > removes EXPERT and moves the configuration option out of the EXPERT > block. > > Signed-off-by: Adrian Reber > Cc: Oleg Nesterov > Cc: Pavel Emelyanov > Cc: Andrew Morton > Cc: Eric W. Biederman &

Re: [PATCH] kconfig: remove EXPERT from CHECKPOINT_RESTORE

To make it easier for distributions to enable CHECKPOINT_RESTORE this > removes EXPERT and moves the configuration option out of the EXPERT > block. > > Signed-off-by: Adrian Reber > Cc: Oleg Nesterov > Cc: Pavel Emelyanov > Cc: Andrew Morton > Cc: Eric W. Biederman &

Re: [PATCH] userfaultfd: prevent non-cooperative events vs mcopy_atomic races

es once the uffd message is read by the monitor. That's > surely way before monitor had chance to somehow process that message. Ouch, yes. This is nasty :( So having no better solution in mind, let's move forward with this. Acked-by: Pavel Emelyanov <xe...@virtuozzo.com>

Re: [PATCH] userfaultfd: prevent non-cooperative events vs mcopy_atomic races

es once the uffd message is read by the monitor. That's > surely way before monitor had chance to somehow process that message. Ouch, yes. This is nasty :( So having no better solution in mind, let's move forward with this. Acked-by: Pavel Emelyanov

Re: [PATCH] userfaultfd: prevent non-cooperative events vs mcopy_atomic races

On 05/24/2018 02:56 PM, Mike Rapoport wrote: > On Thu, May 24, 2018 at 02:24:37PM +0300, Pavel Emelyanov wrote: >> On 05/23/2018 10:42 AM, Mike Rapoport wrote: >>> If a process monitored with userfaultfd changes it's memory mappings or >>> forks() at the same time as uff

Re: [PATCH] userfaultfd: prevent non-cooperative events vs mcopy_atomic races

On 05/24/2018 02:56 PM, Mike Rapoport wrote: > On Thu, May 24, 2018 at 02:24:37PM +0300, Pavel Emelyanov wrote: >> On 05/23/2018 10:42 AM, Mike Rapoport wrote: >>> If a process monitored with userfaultfd changes it's memory mappings or >>> forks() at the same time as uff

Re: [PATCH] userfaultfd: prevent non-cooperative events vs mcopy_atomic races

he non-cooperative events. In > such case we return -EAGAIN and the uffd monitor can understand that > userfaultfd_copy() clashed with a non-cooperative event and take an > appropriate action. > > Signed-off-by: Mike Rapoport <r...@linux.vnet.ibm.com> > Cc: Andrea Arcangeli &

Re: [PATCH] userfaultfd: prevent non-cooperative events vs mcopy_atomic races

he non-cooperative events. In > such case we return -EAGAIN and the uffd monitor can understand that > userfaultfd_copy() clashed with a non-cooperative event and take an > appropriate action. > > Signed-off-by: Mike Rapoport > Cc: Andrea Arcangeli >

Re: [PATCH 3/3] userfaultfd: non-cooperative: allow synchronous EVENT_REMOVE

> @@ -52,6 +53,7 @@ > #define _UFFDIO_WAKE (0x02) > #define _UFFDIO_COPY (0x03) > #define _UFFDIO_ZEROPAGE (0x04) > +#define _UFFDIO_WAKE_SYNC_EVENT (0x05) Excuse my ignorance, but what's the difference between UFFDIO_WAKE and

Re: [PATCH 3/3] userfaultfd: non-cooperative: allow synchronous EVENT_REMOVE

> @@ -52,6 +53,7 @@ > #define _UFFDIO_WAKE (0x02) > #define _UFFDIO_COPY (0x03) > #define _UFFDIO_ZEROPAGE (0x04) > +#define _UFFDIO_WAKE_SYNC_EVENT (0x05) Excuse my ignorance, but what's the difference between UFFDIO_WAKE and

Re: [PATCH v5 0/4] vm: add a syscall to map a process memory into a pipe

On 02/27/2018 05:18 AM, Dmitry V. Levin wrote: > On Mon, Feb 26, 2018 at 12:02:25PM +0300, Pavel Emelyanov wrote: >> On 02/21/2018 03:44 AM, Andrew Morton wrote: >>> On Tue, 9 Jan 2018 08:30:49 +0200 Mike Rapoport <r...@linux.vnet.ibm.com> >>> wrote: >

Re: [PATCH v5 0/4] vm: add a syscall to map a process memory into a pipe

On 02/27/2018 05:18 AM, Dmitry V. Levin wrote: > On Mon, Feb 26, 2018 at 12:02:25PM +0300, Pavel Emelyanov wrote: >> On 02/21/2018 03:44 AM, Andrew Morton wrote: >>> On Tue, 9 Jan 2018 08:30:49 +0200 Mike Rapoport >>> wrote: >>> >>>> This pat

Re: [PATCH v5 0/4] vm: add a syscall to map a process memory into a pipe

On 02/21/2018 03:44 AM, Andrew Morton wrote: > On Tue, 9 Jan 2018 08:30:49 +0200 Mike Rapoport > wrote: > >> This patches introduces new process_vmsplice system call that combines >> functionality of process_vm_read and vmsplice. > > All seems fairly strightforward.

Re: [PATCH v5 0/4] vm: add a syscall to map a process memory into a pipe

On 02/21/2018 03:44 AM, Andrew Morton wrote: > On Tue, 9 Jan 2018 08:30:49 +0200 Mike Rapoport > wrote: > >> This patches introduces new process_vmsplice system call that combines >> functionality of process_vm_read and vmsplice. > > All seems fairly strightforward. The big question is: do

Re: [PATCH 1/4] fs/notify: fdinfo can report unsupported file handles.

On 12/11/2017 05:08 PM, Amir Goldstein wrote: > On Mon, Dec 11, 2017 at 3:46 PM, Pavel Emelyanov <xe...@virtuozzo.com> wrote: >> On 12/11/2017 10:05 AM, Amir Goldstein wrote: >>> On Mon, Dec 11, 2017 at 8:41 AM, Amir Goldstein <amir7...@gmail.com> wrote: >&g

Re: [PATCH 1/4] fs/notify: fdinfo can report unsupported file handles.

On 12/11/2017 05:08 PM, Amir Goldstein wrote: > On Mon, Dec 11, 2017 at 3:46 PM, Pavel Emelyanov wrote: >> On 12/11/2017 10:05 AM, Amir Goldstein wrote: >>> On Mon, Dec 11, 2017 at 8:41 AM, Amir Goldstein wrote: >>>> On Mon, Dec 11, 2017 at 8:04 AM, NeilBrown wro

Re: [PATCH 1/4] fs/notify: fdinfo can report unsupported file handles.

On 12/11/2017 10:05 AM, Amir Goldstein wrote: > On Mon, Dec 11, 2017 at 8:41 AM, Amir Goldstein wrote: >> On Mon, Dec 11, 2017 at 8:04 AM, NeilBrown wrote: >>> If a filesystem does not set sb->s_export_op, then it >>> does not support filehandles and

Re: [PATCH 1/4] fs/notify: fdinfo can report unsupported file handles.

On 12/11/2017 10:05 AM, Amir Goldstein wrote: > On Mon, Dec 11, 2017 at 8:41 AM, Amir Goldstein wrote: >> On Mon, Dec 11, 2017 at 8:04 AM, NeilBrown wrote: >>> If a filesystem does not set sb->s_export_op, then it >>> does not support filehandles and export_fs_encode_fh() >>> and

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On 05/24/2017 02:31 PM, Vlastimil Babka wrote: > On 05/24/2017 12:39 PM, Mike Rapoport wrote: >>> Hm so the prctl does: >>> >>> if (arg2) >>> me->mm->def_flags |= VM_NOHUGEPAGE; >>> else >>> me->mm->def_flags &=

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On 05/24/2017 02:31 PM, Vlastimil Babka wrote: > On 05/24/2017 12:39 PM, Mike Rapoport wrote: >>> Hm so the prctl does: >>> >>> if (arg2) >>> me->mm->def_flags |= VM_NOHUGEPAGE; >>> else >>> me->mm->def_flags &=

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On 05/24/2017 02:18 PM, Michal Hocko wrote: > On Wed 24-05-17 13:39:48, Mike Rapoport wrote: >> On Wed, May 24, 2017 at 09:58:06AM +0200, Vlastimil Babka wrote: >>> On 05/24/2017 09:50 AM, Mike Rapoport wrote: On Mon, May 22, 2017 at 05:52:47PM +0200, Vlastimil Babka wrote: > On

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

On 05/24/2017 02:18 PM, Michal Hocko wrote: > On Wed 24-05-17 13:39:48, Mike Rapoport wrote: >> On Wed, May 24, 2017 at 09:58:06AM +0200, Vlastimil Babka wrote: >>> On 05/24/2017 09:50 AM, Mike Rapoport wrote: On Mon, May 22, 2017 at 05:52:47PM +0200, Vlastimil Babka wrote: > On

Re: [PATCH] Add pidfs filesystem

On 02/22/2017 03:04 PM, Alexey Gladkov wrote: > On Wed, Feb 22, 2017 at 10:40:49AM +0300, Pavel Emelyanov wrote: >> On 02/21/2017 05:57 PM, Oleg Nesterov wrote: >>> On 02/18, Alexey Gladkov wrote: >>>> >>>> This patch allows to mount only the part of /proc

Re: [PATCH] Add pidfs filesystem

On 02/22/2017 03:04 PM, Alexey Gladkov wrote: > On Wed, Feb 22, 2017 at 10:40:49AM +0300, Pavel Emelyanov wrote: >> On 02/21/2017 05:57 PM, Oleg Nesterov wrote: >>> On 02/18, Alexey Gladkov wrote: >>>> >>>> This patch allows to mount only the part of /proc

Re: [RFC 1/3] procfs: fdinfo -- Extend information about epoll target files

On 02/22/2017 11:18 AM, Cyrill Gorcunov wrote: > On Wed, Feb 22, 2017 at 11:09:23AM +0300, Pavel Emelyanov wrote: >>>> >>>> Actually it shouldn't. If you extend the kcmp argument to accept the >>>> epollfd:epollslot pair, this would be effectively the sa

Re: [RFC 1/3] procfs: fdinfo -- Extend information about epoll target files

On 02/22/2017 11:18 AM, Cyrill Gorcunov wrote: > On Wed, Feb 22, 2017 at 11:09:23AM +0300, Pavel Emelyanov wrote: >>>> >>>> Actually it shouldn't. If you extend the kcmp argument to accept the >>>> epollfd:epollslot pair, this would be effectively the sa

Re: [RFC 1/3] procfs: fdinfo -- Extend information about epoll target files

On 02/22/2017 10:54 AM, Cyrill Gorcunov wrote: > On Wed, Feb 22, 2017 at 10:44:07AM +0300, Pavel Emelyanov wrote: >> On 02/21/2017 10:16 PM, Cyrill Gorcunov wrote: >>> On Tue, Feb 21, 2017 at 10:41:12AM -0800, Andy Lutomirski wrote: >>>>> Thus lets add file positi

Re: [RFC 1/3] procfs: fdinfo -- Extend information about epoll target files

On 02/22/2017 10:54 AM, Cyrill Gorcunov wrote: > On Wed, Feb 22, 2017 at 10:44:07AM +0300, Pavel Emelyanov wrote: >> On 02/21/2017 10:16 PM, Cyrill Gorcunov wrote: >>> On Tue, Feb 21, 2017 at 10:41:12AM -0800, Andy Lutomirski wrote: >>>>> Thus lets add file positi

Re: [RFC 1/3] procfs: fdinfo -- Extend information about epoll target files

On 02/21/2017 10:16 PM, Cyrill Gorcunov wrote: > On Tue, Feb 21, 2017 at 10:41:12AM -0800, Andy Lutomirski wrote: >>> Thus lets add file position, inode and device number where >>> this target lays. This three fields can be used as a primary >>> key for sorting, and together with kcmp help CRIU

Re: [RFC 1/3] procfs: fdinfo -- Extend information about epoll target files

On 02/21/2017 10:16 PM, Cyrill Gorcunov wrote: > On Tue, Feb 21, 2017 at 10:41:12AM -0800, Andy Lutomirski wrote: >>> Thus lets add file position, inode and device number where >>> this target lays. This three fields can be used as a primary >>> key for sorting, and together with kcmp help CRIU

Re: [PATCH] Add pidfs filesystem

On 02/21/2017 05:57 PM, Oleg Nesterov wrote: > On 02/18, Alexey Gladkov wrote: >> >> This patch allows to mount only the part of /proc related to pids >> without rest objects. Since this is an addon to /proc, flags applied to >> /proc have an effect on this pidfs filesystem. > > I leave this to

Re: [PATCH] Add pidfs filesystem

On 02/21/2017 05:57 PM, Oleg Nesterov wrote: > On 02/18, Alexey Gladkov wrote: >> >> This patch allows to mount only the part of /proc related to pids >> without rest objects. Since this is an addon to /proc, flags applied to >> /proc have an effect on this pidfs filesystem. > > I leave this to

Re: [CRIU] [PATCH net-next] tcp: allow to enable the repair mode for non-listening sockets

other states we have to dump the same socket > properties, so lets allow to enable repair mode for these sockets. > > The repair mode reveals nothing more for sockets in other states. > > Signed-off-by: Andrei Vagin <ava...@openvz.org> Acked-by: Pavel Emelyanov <xe...@o

Re: [CRIU] [PATCH net-next] tcp: allow to enable the repair mode for non-listening sockets

other states we have to dump the same socket > properties, so lets allow to enable repair mode for these sockets. > > The repair mode reveals nothing more for sockets in other states. > > Signed-off-by: Andrei Vagin Acked-by: Pavel Emelyanov > --- > net/ipv4/tcp.c | 2 +-

Re: [PATCH v2] locks: Filter /proc/locks output on proc pid ns

On 08/03/2016 05:17 PM, Nikolay Borisov wrote: > > > On 08/03/2016 04:46 PM, Jeff Layton wrote: >> On Wed, 2016-08-03 at 10:35 +0300, Nikolay Borisov wrote: >>> On busy container servers reading /proc/locks shows all the locks >>> created by all clients. This can cause large latency spikes. In

Re: [PATCH v2] locks: Filter /proc/locks output on proc pid ns

On 08/03/2016 05:17 PM, Nikolay Borisov wrote: > > > On 08/03/2016 04:46 PM, Jeff Layton wrote: >> On Wed, 2016-08-03 at 10:35 +0300, Nikolay Borisov wrote: >>> On busy container servers reading /proc/locks shows all the locks >>> created by all clients. This can cause large latency spikes. In

Re: [PATCH 0/5] userfaultfd: extension for non cooperative uffd usage

On 03/20/2016 03:42 PM, Mike Rapoport wrote: > Hi, > > This set is to address the issues that appear in userfaultfd usage > scenarios when the task monitoring the uffd and the mm-owner do not > cooperate to each other on VM changes such as remaps, madvises and > fork()-s. > > The pacthes are

Re: [PATCH 0/5] userfaultfd: extension for non cooperative uffd usage

On 03/20/2016 03:42 PM, Mike Rapoport wrote: > Hi, > > This set is to address the issues that appear in userfaultfd usage > scenarios when the task monitoring the uffd and the mm-owner do not > cooperate to each other on VM changes such as remaps, madvises and > fork()-s. > > The pacthes are

Re: [PATCH 0/2] vfs: Define new syscall getumask.

ial system call "getumask" which returns > the umask of the current process. Ah! Thanks for this :) Acked-by: Pavel Emelyanov <xe...@virtuozzo.com>

Re: [PATCH 0/2] vfs: Define new syscall getumask.

ial system call "getumask" which returns > the umask of the current process. Ah! Thanks for this :) Acked-by: Pavel Emelyanov

Re: [PATCH 0/5] userfaultfd: extension for non cooperative uffd usage

. > > The pacthes are essentially the same as in the prevoious respin (1), > they've just been rebased on the current tree. > > [1] http://thread.gmane.org/gmane.linux.kernel.mm/132662 Thanks, Mike! Acked-by: Pavel Emelyanov <xe...@virtuozzo.com>

Re: [PATCH 0/5] userfaultfd: extension for non cooperative uffd usage

. > > The pacthes are essentially the same as in the prevoious respin (1), > they've just been rebased on the current tree. > > [1] http://thread.gmane.org/gmane.linux.kernel.mm/132662 Thanks, Mike! Acked-by: Pavel Emelyanov

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

On 08/14/2015 10:22 AM, Cyrill Gorcunov wrote: > On Thu, Aug 13, 2015 at 01:09:47PM -0700, Linus Torvalds wrote: >> On Thu, Aug 13, 2015 at 1:08 PM, Cyrill Gorcunov wrote: >>> >>> If only I'm not missin something obvious this should not hurt us. >>> But I gonna build test kernel and check to be

Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

On 08/14/2015 10:22 AM, Cyrill Gorcunov wrote: On Thu, Aug 13, 2015 at 01:09:47PM -0700, Linus Torvalds wrote: On Thu, Aug 13, 2015 at 1:08 PM, Cyrill Gorcunov gorcu...@gmail.com wrote: If only I'm not missin something obvious this should not hurt us. But I gonna build test kernel and check

Re: [PATCH v2 1/1] mm: move ->mremap() from file_operations to vm_operations_struct

On 06/25/2015 11:45 PM, Oleg Nesterov wrote: > vma->vm_ops->mremap() looks more natural and clean in move_vma(), > and this way ->mremap() can have more users. Say, vdso. > > While at it, s/aio_ring_remap/aio_ring_mremap/. > > Signed-off-by: Oleg Nesterov

Re: [PATCH v2 1/1] mm: move -mremap() from file_operations to vm_operations_struct

On 06/25/2015 11:45 PM, Oleg Nesterov wrote: vma-vm_ops-mremap() looks more natural and clean in move_vma(), and this way -mremap() can have more users. Say, vdso. While at it, s/aio_ring_remap/aio_ring_mremap/. Signed-off-by: Oleg Nesterov o...@redhat.com Acked-by: Pavel Emelyanov xe

Re: [PATCH 1/1] mm: move ->mremap() from file_operations to vm_operations_struct

On 06/23/2015 09:02 PM, Oleg Nesterov wrote: > vma->vm_ops->mremap() looks more natural and clean in move_vma(), > and this way ->mremap() can have more users. Say, vdso. > > Signed-off-by: Oleg Nesterov Looks-good-to: /me :) Thanks! -- To unsubscribe from this list: send the line "unsubscribe

Re: vdso && f_op->mremap (Was: special_mapping_fault() is broken)

On 06/23/2015 03:47 AM, Oleg Nesterov wrote: > On 06/21, Oleg Nesterov wrote: >> >> Forgot to add Andy... > > Add Pavel ;) > > I never understood why ->mremap() lives in file_operations, not in > vm_operations_struct. To me vma->vm_file->f_op in move_vma() just > looks strange,

Re: vdso f_op-mremap (Was: special_mapping_fault() is broken)

On 06/23/2015 03:47 AM, Oleg Nesterov wrote: On 06/21, Oleg Nesterov wrote: Forgot to add Andy... Add Pavel ;) I never understood why -mremap() lives in file_operations, not in vm_operations_struct. To me vma-vm_file-f_op in move_vma() just looks strange, vma-vm_ops-mremap(new_vma)

Re: [PATCH 1/1] mm: move -mremap() from file_operations to vm_operations_struct

On 06/23/2015 09:02 PM, Oleg Nesterov wrote: vma-vm_ops-mremap() looks more natural and clean in move_vma(), and this way -mremap() can have more users. Say, vdso. Signed-off-by: Oleg Nesterov o...@redhat.com Looks-good-to: /me :) Thanks! -- To unsubscribe from this list: send the line

Re: [PATCH v5] seccomp: add ptrace options for suspend/resume

n favor of a capable() check in ptrace > directly > > v5 changes: > > * check that seccomp is not enabled (or suspended) on the tracer > > Signed-off-by: Tycho Andersen > CC: Kees Cook > CC: Andy Lutomirski > CC: Will Drewry > CC: Roland McGrath > CC: Oleg

Re: [PATCH v5] seccomp: add ptrace options for suspend/resume

tycho.ander...@canonical.com CC: Kees Cook keesc...@chromium.org CC: Andy Lutomirski l...@amacapital.net CC: Will Drewry w...@chromium.org CC: Roland McGrath rol...@hack.frob.com CC: Oleg Nesterov o...@redhat.com CC: Pavel Emelyanov xe...@parallels.com CC: Serge E. Hallyn serge.hal...@ubuntu.com

Re: [PATCH] seccomp: add ptrace commands for suspend/resume

>> +int suspend_seccomp(struct task_struct *task) >> +{ >> +int ret = -EACCES; >> + >> +spin_lock_irq(>sighand->siglock); >> + >> +if (!capable(CAP_SYS_ADMIN)) >> +goto out; > > I am puzzled ;) Why do we need ->siglock? And even if we need it, why > we can't check

Re: [PATCH] seccomp: add ptrace commands for suspend/resume

+int suspend_seccomp(struct task_struct *task) +{ +int ret = -EACCES; + +spin_lock_irq(task-sighand-siglock); + +if (!capable(CAP_SYS_ADMIN)) +goto out; I am puzzled ;) Why do we need -siglock? And even if we need it, why we can't check CAP_SYS_ADMIN lockless?

Re: [PATCH 00/23] userfaultfd v4

e faults than what was available before > (PROT_NONE + SIGSEGV trap). Not to spam with 23 e-mails, all patches are Acked-by: Pavel Emelyanov Thanks! -- Pavel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kerne

Re: [PATCH 00/23] userfaultfd v4

+ SIGSEGV trap). Not to spam with 23 e-mails, all patches are Acked-by: Pavel Emelyanov xe...@parallels.com Thanks! -- Pavel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org

[PATCH 3/5] uffd: Add fork() event

to the userfaultfd_ctx_read() to handle the ctx queues' locking vs file creation. Another thing worth noticing is that the task that fork()-s waits for the uffd event to get processed WITHOUT the mmap sem. Signed-off-by: Pavel Emelyanov --- fs/userfaultfd.c | 137

[PATCH 5/5] uffd: Add madvise() event for MADV_DONTNEED request

If the page is punched out of the address space the uffd reader should know this and zeromap the respective area in case of the #PF event. Signed-off-by: Pavel Emelyanov --- fs/userfaultfd.c | 26 ++ include/linux/userfaultfd_k.h| 10

[PATCH 4/5] uffd: Add mremap() event

s for fork event. Signed-off-by: Pavel Emelyanov --- fs/userfaultfd.c | 35 +++ include/linux/userfaultfd_k.h| 12 include/uapi/linux/userfaultfd.h | 10 +- mm/mremap.c | 31 --

[PATCH 2/5] uffd: Add ability to report non-PF events from uffd descriptor

ser-space. Signed-off-by: Pavel Emelyanov --- fs/userfaultfd.c | 97 ++-- 1 file changed, 95 insertions(+), 2 deletions(-) diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c index c593a72..83acb19 100644 --- a/fs/userfaultfd.c +++ b/fs/userfaultf

[PATCH 1/5] uffd: Split the find_userfault() routine

I will need one to lookup for userfaultfd_wait_queue-s in different wait queue. Signed-off-by: Pavel Emelyanov --- fs/userfaultfd.c | 18 -- 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c index c89e96f..c593a72 100644 --- a/fs

[PATCH 0/5] UserfaultFD: Extension for non cooperative uffd usage (v2)

Hi, This set is to address the issues that appear in userfaultfd usage scenarios when the task monitoring the uffd and the mm-owner do not cooperate to each other on VM changes such as remaps, madvises and fork()-s. This is the re-based set on the recent userfaultfd branch, two major changes

[PATCH 3/5] uffd: Add fork() event

to the userfaultfd_ctx_read() to handle the ctx queues' locking vs file creation. Another thing worth noticing is that the task that fork()-s waits for the uffd event to get processed WITHOUT the mmap sem. Signed-off-by: Pavel Emelyanov xe...@parallels.com --- fs/userfaultfd.c | 137

[PATCH 0/5] UserfaultFD: Extension for non cooperative uffd usage (v2)

Hi, This set is to address the issues that appear in userfaultfd usage scenarios when the task monitoring the uffd and the mm-owner do not cooperate to each other on VM changes such as remaps, madvises and fork()-s. This is the re-based set on the recent userfaultfd branch, two major changes

[PATCH 1/5] uffd: Split the find_userfault() routine

I will need one to lookup for userfaultfd_wait_queue-s in different wait queue. Signed-off-by: Pavel Emelyanov xe...@parallels.com --- fs/userfaultfd.c | 18 -- 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c index c89e96f

[PATCH 2/5] uffd: Add ability to report non-PF events from uffd descriptor

-space. Signed-off-by: Pavel Emelyanov xe...@parallels.com --- fs/userfaultfd.c | 97 ++-- 1 file changed, 95 insertions(+), 2 deletions(-) diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c index c593a72..83acb19 100644 --- a/fs/userfaultfd.c

[PATCH 4/5] uffd: Add mremap() event

event. Signed-off-by: Pavel Emelyanov xe...@parallels.com --- fs/userfaultfd.c | 35 +++ include/linux/userfaultfd_k.h| 12 include/uapi/linux/userfaultfd.h | 10 +- mm/mremap.c | 31

[PATCH 5/5] uffd: Add madvise() event for MADV_DONTNEED request

If the page is punched out of the address space the uffd reader should know this and zeromap the respective area in case of the #PF event. Signed-off-by: Pavel Emelyanov xe...@parallels.com --- fs/userfaultfd.c | 26 ++ include/linux/userfaultfd_k.h

Re: [PATCH 2/3] uffd: Introduce the v2 API

On 04/28/2015 12:12 AM, Andrea Arcangeli wrote: > Hello, > > On Thu, Apr 23, 2015 at 09:29:07AM +0300, Pavel Emelyanov wrote: >> So your proposal is to always report 16 bytes per PF from read() and >> let userspace decide itself how to handle the result? > > Reading

Re: [PATCH 2/3] uffd: Introduce the v2 API

On 04/28/2015 12:12 AM, Andrea Arcangeli wrote: Hello, On Thu, Apr 23, 2015 at 09:29:07AM +0300, Pavel Emelyanov wrote: So your proposal is to always report 16 bytes per PF from read() and let userspace decide itself how to handle the result? Reading 16bytes for each userfault (instead

Re: [PATCH 0/3] UserfaultFD: Extension for non cooperative uffd usage

On 04/21/2015 03:02 PM, Andrea Arcangeli wrote: > Hi Pavel, > > On Wed, Mar 18, 2015 at 10:34:26PM +0300, Pavel Emelyanov wrote: >> Hi, >> >> On the recent LSF Andrea presented his userfault-fd patches and >> I had shown some issues that appear in usage scenario

Re: [PATCH 2/3] uffd: Introduce the v2 API

On 04/21/2015 03:18 PM, Andrea Arcangeli wrote: > On Wed, Mar 18, 2015 at 10:35:17PM +0300, Pavel Emelyanov wrote: >> +if (!(ctx->features & UFFD_FEATURE_LONGMSG)) { > > If we are to use different protocols, it'd be nicer to have two > di

Re: [PATCH 0/3] UserfaultFD: Extension for non cooperative uffd usage

On 04/21/2015 03:02 PM, Andrea Arcangeli wrote: Hi Pavel, On Wed, Mar 18, 2015 at 10:34:26PM +0300, Pavel Emelyanov wrote: Hi, On the recent LSF Andrea presented his userfault-fd patches and I had shown some issues that appear in usage scenarios when the monitor task and mm task do

Re: [PATCH 2/3] uffd: Introduce the v2 API

On 04/21/2015 03:18 PM, Andrea Arcangeli wrote: On Wed, Mar 18, 2015 at 10:35:17PM +0300, Pavel Emelyanov wrote: +if (!(ctx-features UFFD_FEATURE_LONGMSG)) { If we are to use different protocols, it'd be nicer to have two different methods to assign to userfaultfd_fops.read

Re: [RESEND PATCH v3 1/2] mm: Introducing arch_remap hook

ide the scope of the patchset, I guess. >>> >>> I don't see any better candidate for such dummy header. :-/ >> >> Clearly, I'm not confortable with a rewrite of :( >> >> So what about this patch, is this v3 acceptable ? > > Acked-by: Kirill A. Shutem

Re: [RESEND PATCH v3 1/2] mm: Introducing arch_remap hook

On 04/13/2015 04:21 PM, Laurent Dufour wrote: > On 13/04/2015 15:13, Kirill A. Shutemov wrote: >> On Mon, Apr 13, 2015 at 02:41:22PM +0200, Laurent Dufour wrote: >>> On 13/04/2015 13:58, Kirill A. Shutemov wrote: On Mon, Apr 13, 2015 at 11:56:27AM +0200, Laurent Dufour wrote: > Some

Re: [RESEND PATCH v3 1/2] mm: Introducing arch_remap hook

Other than the #ifdef thing, the same: Acked-by: Pavel Emelyanov xe...@parallels.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read

Re: [RESEND PATCH v3 1/2] mm: Introducing arch_remap hook

On 04/13/2015 04:21 PM, Laurent Dufour wrote: On 13/04/2015 15:13, Kirill A. Shutemov wrote: On Mon, Apr 13, 2015 at 02:41:22PM +0200, Laurent Dufour wrote: On 13/04/2015 13:58, Kirill A. Shutemov wrote: On Mon, Apr 13, 2015 at 11:56:27AM +0200, Laurent Dufour wrote: Some architecture would

Re: [PATCH v3 1/2] x86_64,signal: Fix SS handling for signals delivered to 64-bit programs

On 03/19/2015 12:26 AM, Andy Lutomirski wrote: > On Wed, Mar 18, 2015 at 1:02 PM, Oleg Nesterov wrote: >> On 03/18, Andrey Wagin wrote: >>> >>> This patch fixes the problem. Oleg, could you send this path in the >>> criu maillist? >> >> Sure, will do. > > We still haven't answered one question:

[PATCH 3/3] uffd: Introduce fork() notification

number and will be able to start reading events from the new task. The fork() of mm with uffd attached doesn't finish until the monitor "acks" the message by reading the new uffd descriptor. Signed-off-by: Pavel Emelyanov --- fs/userfaultfd.c

[PATCH 2/3] uffd: Introduce the v2 API

spectively). Signed-off-by: Pavel Emelyanov --- fs/userfaultfd.c | 56 ++-- include/uapi/linux/userfaultfd.h | 21 ++- 2 files changed, 62 insertions(+), 15 deletions(-) diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c index 6c9a2d

[PATCH 0/3] UserfaultFD: Extension for non cooperative uffd usage

Hi, On the recent LSF Andrea presented his userfault-fd patches and I had shown some issues that appear in usage scenarios when the monitor task and mm task do not cooperate to each other on VM changes (and fork()-s). Here's the implementation of the extended uffd API that would help us to

[PATCH 1/3] uffd: Tossing bits around

Reformat the existing code a bit to make it easier for further patching. Signed-off-by: Pavel Emelyanov --- fs/userfaultfd.c | 37 - 1 file changed, 28 insertions(+), 9 deletions(-) diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c index b4c7f25..6c9a2d6

[PATCH 1/3] uffd: Tossing bits around

Reformat the existing code a bit to make it easier for further patching. Signed-off-by: Pavel Emelyanov xe...@parallels.com --- fs/userfaultfd.c | 37 - 1 file changed, 28 insertions(+), 9 deletions(-) diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c index

[PATCH 3/3] uffd: Introduce fork() notification

number and will be able to start reading events from the new task. The fork() of mm with uffd attached doesn't finish until the monitor acks the message by reading the new uffd descriptor. Signed-off-by: Pavel Emelyanov xe...@parallels.com --- fs/userfaultfd.c | 175

[PATCH 2/3] uffd: Introduce the v2 API

). Signed-off-by: Pavel Emelyanov xe...@parallels.com --- fs/userfaultfd.c | 56 ++-- include/uapi/linux/userfaultfd.h | 21 ++- 2 files changed, 62 insertions(+), 15 deletions(-) diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c index

[PATCH 0/3] UserfaultFD: Extension for non cooperative uffd usage

Hi, On the recent LSF Andrea presented his userfault-fd patches and I had shown some issues that appear in usage scenarios when the monitor task and mm task do not cooperate to each other on VM changes (and fork()-s). Here's the implementation of the extended uffd API that would help us to

Re: [PATCH v3 1/2] x86_64,signal: Fix SS handling for signals delivered to 64-bit programs

On 03/19/2015 12:26 AM, Andy Lutomirski wrote: On Wed, Mar 18, 2015 at 1:02 PM, Oleg Nesterov o...@redhat.com wrote: On 03/18, Andrey Wagin wrote: This patch fixes the problem. Oleg, could you send this path in the criu maillist? Sure, will do. We still haven't answered one question:

Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace

/03/exploiting-dram-rowhammer-bug-to-gain.html > > Signed-off-by: Kirill A. Shutemov > Cc: Pavel Emelyanov > Cc: Konstantin Khlebnikov > Cc: Andrew Morton > Cc: Linus Torvalds > Cc: Mark Seaborn > Cc: Andy Lutomirski > --- > fs/proc/task_mmu.c | 3 +++ > 1 file cha

Re: [RFC, PATCH] pagemap: do not leak physical addresses to non-privileged userspace

-to-gain.html Signed-off-by: Kirill A. Shutemov kirill.shute...@linux.intel.com Cc: Pavel Emelyanov xe...@parallels.com Cc: Konstantin Khlebnikov khlebni...@openvz.org Cc: Andrew Morton a...@linux-foundation.org Cc: Linus Torvalds torva...@linux-foundation.org Cc: Mark Seaborn mseab...@chromium.org

Re: [PATCH 00/21] RFC: userfaultfd v3

> All UFFDIO_COPY/ZEROPAGE/REMAP methods already support CRIU postcopy > live migration and the UFFD can be passed to a manager process through > unix domain sockets to satisfy point 5). Yup :) That's the best (from my POV) point of ufd -- the ability to delegate the descriptor to some other

Re: [PATCH 14/21] userfaultfd: mcopy_atomic|mfill_zeropage: UFFDIO_COPY|UFFDIO_ZEROPAGE preparation

> +static int mcopy_atomic_pte(struct mm_struct *dst_mm, > + pmd_t *dst_pmd, > + struct vm_area_struct *dst_vma, > + unsigned long dst_addr, > + unsigned long src_addr) > +{ > + struct mem_cgroup

Re: [PATCH 19/21] userfaultfd: remap_pages: UFFDIO_REMAP preparation

> +ssize_t remap_pages(struct mm_struct *dst_mm, struct mm_struct *src_mm, > + unsigned long dst_start, unsigned long src_start, > + unsigned long len, __u64 mode) > +{ > + struct vm_area_struct *src_vma, *dst_vma; > + long err = -EINVAL; > + pmd_t

Re: [PATCH 10/21] userfaultfd: add new syscall to provide memory externalization

> +int handle_userfault(struct vm_area_struct *vma, unsigned long address, > + unsigned int flags, unsigned long reason) > +{ > + struct mm_struct *mm = vma->vm_mm; > + struct userfaultfd_ctx *ctx; > + struct userfaultfd_wait_queue uwq; > + > +

Re: [PATCH 05/21] userfaultfd: add vm_userfaultfd_ctx to the vm_area_struct

> diff --git a/kernel/fork.c b/kernel/fork.c > index cf65139..cb215c0 100644 > --- a/kernel/fork.c > +++ b/kernel/fork.c > @@ -425,6 +425,7 @@ static int dup_mmap(struct mm_struct *mm, struct > mm_struct *oldmm) > goto fail_nomem_anon_vma_fork; > tmp->vm_flags

Re: [PATCH 05/21] userfaultfd: add vm_userfaultfd_ctx to the vm_area_struct

diff --git a/kernel/fork.c b/kernel/fork.c index cf65139..cb215c0 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -425,6 +425,7 @@ static int dup_mmap(struct mm_struct *mm, struct mm_struct *oldmm) goto fail_nomem_anon_vma_fork; tmp-vm_flags =

Re: [PATCH 10/21] userfaultfd: add new syscall to provide memory externalization

+int handle_userfault(struct vm_area_struct *vma, unsigned long address, + unsigned int flags, unsigned long reason) +{ + struct mm_struct *mm = vma-vm_mm; + struct userfaultfd_ctx *ctx; + struct userfaultfd_wait_queue uwq; + +

Re: [PATCH 19/21] userfaultfd: remap_pages: UFFDIO_REMAP preparation

+ssize_t remap_pages(struct mm_struct *dst_mm, struct mm_struct *src_mm, + unsigned long dst_start, unsigned long src_start, + unsigned long len, __u64 mode) +{ + struct vm_area_struct *src_vma, *dst_vma; + long err = -EINVAL; + pmd_t *src_pmd,

  1   2   3   4   5   6   7   8   9   10   >