From: Oleg Nesterov <oleg@redhat.com>
To: "Adalbert Lazăr" <alazar@bitdefender.com>
Cc: linux-mm@kvack.org, linux-api@vger.kernel.org,
"Andrew Morton" <akpm@linux-foundation.org>,
"Alexander Graf" <graf@amazon.com>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Jerome Glisse" <jglisse@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Mihai Donțu" <mdontu@bitdefender.com>,
"Mircea Cirjaliu" <mcirjaliu@bitdefender.com>,
"Andy Lutomirski" <luto@kernel.org>,
"Arnd Bergmann" <arnd@arndb.de>,
"Sargun Dhillon" <sargun@sargun.me>,
"Aleksa Sarai" <cyphar@cyphar.com>,
"Jann Horn" <jannh@google.com>,
"Kees Cook" <keescook@chromium.org>,
"Matthew Wilcox" <willy@infradead.org>,
"Christian Brauner" <christian.brauner@ubuntu.com>
Subject: Re: [RESEND RFC PATCH 4/5] mm/remote_mapping: use a pidfd to access memory belonging to unrelated process
Date: Mon, 7 Sep 2020 16:30:08 +0200 [thread overview]
Message-ID: <20200907143008.GB31050@redhat.com> (raw)
In-Reply-To: <20200904113116.20648-5-alazar@bitdefender.com>
it seems that nobody is going to review this patch ;)
So I tried to read mirror_vm_fault() and the usage of mmap_sem doesn't
look right to me. But let me repeat, this is not my area I can be easily
wrong, please correct me.
On 09/04, Adalbert Lazăr wrote:
>
> +static vm_fault_t mirror_vm_fault(struct vm_fault *vmf)
> +{
> + struct vm_area_struct *vma = vmf->vma;
> + struct mm_struct *mm = vma->vm_mm;
> + struct remote_vma_context *ctx = vma->vm_private_data;
> + struct remote_view *view = ctx->view;
> + struct file *file = vma->vm_file;
> + struct remote_file_context *fctx = file->private_data;
> + unsigned long req_addr;
> + unsigned int gup_flags;
> + struct page *req_page;
> + vm_fault_t result = VM_FAULT_SIGBUS;
> + struct mm_struct *src_mm = fctx->mm;
> + unsigned long seq;
> + int idx;
> +
> +fault_retry:
> + seq = mmu_interval_read_begin(&view->mmin);
> +
> + idx = srcu_read_lock(&fctx->fault_srcu);
> +
> + /* check if view was invalidated */
> + if (unlikely(!READ_ONCE(view->valid))) {
> + pr_debug("%s: region [%lx-%lx) was invalidated!!\n", __func__,
> + view->offset, view->offset + view->size);
> + goto out_invalid; /* VM_FAULT_SIGBUS */
> + }
> +
> + /* drop current mm semapchore */
> + up_read(¤t->mm->mmap_sem);
Please use mmap_read_lock/unlock(mm) instead of down/up_read(mmap_sem).
But why is it safe to drop ->mmap_sem without checking
FAULT_FLAG_ALLOW_RETRY/RETRY_NOWAIT ?
> + /* take remote mm semaphore */
> + if (vmf->flags & FAULT_FLAG_ALLOW_RETRY) {
> + if (!down_read_trylock(&src_mm->mmap_sem)) {
I don't understand this... perhaps you meant FAULT_FLAG_RETRY_NOWAIT ?
> + * If FAULT_FLAG_ALLOW_RETRY is set, the mmap_sem must be released
> + * before returning VM_FAULT_RETRY only if FAULT_FLAG_RETRY_NOWAIT is
> + * not set.
Well, iiuc FAULT_FLAG_ALLOW_RETRY means that ->fault() _can_ drop mmap_sem
and return VM_FAULT_RETRY (unless NOWAIT).
> + if (vmf->flags & (FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_TRIED)) {
> + if (!(vmf->flags & FAULT_FLAG_KILLABLE))
> + if (current && fatal_signal_pending(current)) {
> + up_read(¤t->mm->mmap_sem);
> + return VM_FAULT_RETRY;
I fail to understand this. But in any case, you do not need to check
current != NULL and up_read() looks wrong if RETRY_NOWAIT?
Oleg.
next prev parent reply other threads:[~2020-09-07 14:31 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-04 11:31 [RESEND RFC PATCH 0/5] Remote mapping Adalbert Lazăr
2020-09-04 11:31 ` [RESEND RFC PATCH 1/5] mm: add atomic capability to zap_details Adalbert Lazăr
2020-09-04 11:31 ` [RESEND RFC PATCH 2/5] mm: let the VMA decide how zap_pte_range() acts on mapped pages Adalbert Lazăr
2020-09-04 11:31 ` [RESEND RFC PATCH 3/5] mm/mmu_notifier: remove lockdep map, allow mmu notifier to be used in nested scenarios Adalbert Lazăr
2020-09-04 12:03 ` Jason Gunthorpe
2020-09-04 11:31 ` [RESEND RFC PATCH 4/5] mm/remote_mapping: use a pidfd to access memory belonging to unrelated process Adalbert Lazăr
2020-09-04 17:55 ` Oleg Nesterov
2020-09-07 14:30 ` Oleg Nesterov [this message]
2020-09-07 15:16 ` Adalbert Lazăr
2020-09-09 8:32 ` Mircea CIRJALIU - MELIU
2020-09-10 16:43 ` Oleg Nesterov
2020-09-07 15:02 ` Christian Brauner
2020-09-07 16:04 ` Mircea CIRJALIU - MELIU
2020-09-04 11:31 ` [RESEND RFC PATCH 5/5] pidfd_mem: implemented remote memory mapping system call Adalbert Lazăr
2020-09-04 19:18 ` Florian Weimer
2020-09-07 14:55 ` Christian Brauner
2020-09-04 12:11 ` [RESEND RFC PATCH 0/5] Remote mapping Jason Gunthorpe
2020-09-04 13:24 ` Mircea CIRJALIU - MELIU
2020-09-04 13:39 ` Jason Gunthorpe
2020-09-04 14:18 ` Mircea CIRJALIU - MELIU
2020-09-04 14:39 ` Jason Gunthorpe
2020-09-04 15:40 ` Mircea CIRJALIU - MELIU
2020-09-04 16:11 ` Jason Gunthorpe
2020-09-04 19:41 ` Matthew Wilcox
2020-09-04 19:49 ` Jason Gunthorpe
2020-09-04 20:08 ` Paolo Bonzini
2020-12-01 18:01 ` Jason Gunthorpe
2020-09-04 19:19 ` Florian Weimer
2020-09-04 20:18 ` Paolo Bonzini
2020-09-07 8:33 ` Christian Brauner
2020-09-04 19:39 ` Andy Lutomirski
2020-09-04 20:09 ` Paolo Bonzini
2020-09-04 20:34 ` Andy Lutomirski
2020-09-04 21:58 ` Paolo Bonzini
2020-09-04 23:17 ` Andy Lutomirski
2020-09-05 18:27 ` Paolo Bonzini
2020-09-07 8:38 ` Christian Brauner
2020-09-07 12:41 ` Mircea CIRJALIU - MELIU
2020-09-07 7:05 ` Christoph Hellwig
2020-09-07 8:44 ` Paolo Bonzini
2020-09-07 10:25 ` Mircea CIRJALIU - MELIU
2020-09-07 15:05 ` Christian Brauner
2020-09-07 20:43 ` Andy Lutomirski
2020-09-09 11:38 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200907143008.GB31050@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alazar@bitdefender.com \
--cc=arnd@arndb.de \
--cc=christian.brauner@ubuntu.com \
--cc=cyphar@cyphar.com \
--cc=graf@amazon.com \
--cc=jannh@google.com \
--cc=jglisse@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mcirjaliu@bitdefender.com \
--cc=mdontu@bitdefender.com \
--cc=pbonzini@redhat.com \
--cc=sargun@sargun.me \
--cc=stefanha@redhat.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.