From: Christoph Hellwig <hch@infradead.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, jgg@ziepe.ca,
linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
dan.j.williams@intel.com
Subject: Re: [PATCH 1/2] mm: provide a sane PTE walking API for modules
Date: Mon, 8 Feb 2021 17:39:36 +0000 [thread overview]
Message-ID: <20210208173936.GA1496438@infradead.org> (raw)
In-Reply-To: <20210205103259.42866-2-pbonzini@redhat.com>
> +int follow_invalidate_pte(struct mm_struct *mm, unsigned long address,
> + struct mmu_notifier_range *range, pte_t **ptepp, pmd_t **pmdpp,
> + spinlock_t **ptlp);
This adds a very pointless overy long line.
> +/**
> + * follow_pte - look up PTE at a user virtual address
> + * @vma: memory mapping
> + * @address: user virtual address
> + * @ptepp: location to store found PTE
> + * @ptlp: location to store the lock for the PTE
> + *
> + * On a successful return, the pointer to the PTE is stored in @ptepp;
> + * the corresponding lock is taken and its location is stored in @ptlp.
> + * The contents of the PTE are only stable until @ptlp is released;
> + * any further use, if any, must be protected against invalidation
> + * with MMU notifiers.
> + *
> + * Only IO mappings and raw PFN mappings are allowed. The mmap semaphore
> + * should be taken for read.
> + *
> + * Return: zero on success, -ve otherwise.
> + */
> +int follow_pte(struct mm_struct *mm, unsigned long address,
> + pte_t **ptepp, spinlock_t **ptlp)
> +{
> + return follow_invalidate_pte(mm, address, NULL, ptepp, NULL, ptlp);
> +}
> +EXPORT_SYMBOL_GPL(follow_pte);
I still don't think this is good as a general API. Please document this
as KVM only for now, and hopefully next merge window I'll finish an
export variant restricting us to specific modules.
next prev parent reply other threads:[~2021-02-08 17:39 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-05 10:32 [PATCH 0/2] KVM: do not assume PTE is writable after follow_pfn Paolo Bonzini
2021-02-05 10:32 ` [PATCH 1/2] mm: provide a sane PTE walking API for modules Paolo Bonzini
2021-02-05 13:49 ` Jason Gunthorpe
2021-02-08 17:39 ` Christoph Hellwig [this message]
2021-02-08 18:18 ` Paolo Bonzini
2021-02-09 8:14 ` Christoph Hellwig
2021-02-09 9:19 ` Paolo Bonzini
2021-02-05 10:32 ` [PATCH 2/2] KVM: do not assume PTE is writable after follow_pfn Paolo Bonzini
2021-02-05 15:43 ` kernel test robot
2021-02-05 17:41 ` kernel test robot
2021-02-05 18:14 ` [PATCH 0/2] " Peter Xu
2021-02-08 18:51 ` Jason Gunthorpe
2021-02-08 22:02 ` Peter Xu
2021-02-08 23:26 ` Jason Gunthorpe
2021-02-09 0:23 ` Peter Xu
2021-02-09 8:19 ` Christoph Hellwig
2021-02-09 10:02 ` Joao Martins
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=20210208173936.GA1496438@infradead.org \
--to=hch@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=jgg@ziepe.ca \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pbonzini@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).