All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Souptick Joarder <jrdr.linux@gmail.com>
Cc: linux@armlinux.org.uk, miguel.ojeda.sandonis@gmail.com,
	robin@protonic.nl, stefanr@s5r6.in-berlin.de, hjc@rock-chips.com,
	heiko@sntech.de, airlied@linux.ie, robin.murphy@arm.com,
	iamjoonsoo.kim@lge.com, akpm@linux-foundation.org,
	m.szyprowski@samsung.com, keescook@chromium.org,
	treding@nvidia.com, mhocko@suse.com, dan.j.williams@intel.com,
	kirill.shutemov@linux.intel.com, mark.rutland@arm.com,
	aryabinin@virtuozzo.com, dvyukov@google.com,
	kstewart@linuxfoundation.org, tchibo@google.com, riel@redhat.com,
	minchan@kernel.org, peterz@infradead.org, ying.huang@intel.com,
	ak@linux.intel.com, rppt@linux.vnet.ibm.com,
	linux@dominikbrodowski.net, arnd@arndb.de,
	cpandya@codeaurora.org, hannes@cmpxchg.org, joe@perches.com,
	mcgrof@kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	linux1394-devel@lists.sourceforge.net,
	dri-devel@lists.freedesktop.org,
	linux-rockchip@lists.infradead.org, linux-mm@kvack.org
Subject: Re: [PATCH v2] mm: Introduce new function vm_insert_kmem_page
Date: Wed, 3 Oct 2018 13:00:03 -0700	[thread overview]
Message-ID: <20181003200003.GA9965@bombadil.infradead.org> (raw)
In-Reply-To: <20181003185854.GA1174@jordon-HP-15-Notebook-PC>

On Thu, Oct 04, 2018 at 12:28:54AM +0530, Souptick Joarder wrote:
> These are the approaches which could have been taken to handle
> this scenario -
> 
> *  Replace vm_insert_page with vmf_insert_page and then write few
>    extra lines of code to convert VM_FAULT_CODE to errno which
>    makes driver users more complex ( also the reverse mapping errno to
>    VM_FAULT_CODE have been cleaned up as part of vm_fault_t migration ,
>    not preferred to introduce anything similar again)
> 
> *  Maintain both vm_insert_page and vmf_insert_page and use it in
>    respective places. But it won't gurantee that vm_insert_page will
>    never be used in #PF context.
> 
> *  Introduce a similar API like vm_insert_page, convert all non #PF
>    consumer to use it and finally remove vm_insert_page by converting
>    it to vmf_insert_page.
> 
> And the 3rd approach was taken by introducing vm_insert_kmem_page().
> 
> In short, vmf_insert_page will be used in page fault handlers
> context and vm_insert_kmem_page will be used to map kernel
> memory to user vma outside page fault handlers context.

As far as I can tell, vm_insert_kmem_page() is line-for-line identical
with vm_insert_page().  Seriously, here's a diff I just did:

-static int insert_page(struct vm_area_struct *vma, unsigned long addr,
-                       struct page *page, pgprot_t prot)
+static int insert_kmem_page(struct vm_area_struct *vma, unsigned long addr,
+               struct page *page, pgprot_t prot)
-       /* Ok, finally just insert the thing.. */
-int vm_insert_page(struct vm_area_struct *vma, unsigned long addr,
+int vm_insert_kmem_page(struct vm_area_struct *vma, unsigned long addr,
-       return insert_page(vma, addr, page, vma->vm_page_prot);
+       return insert_kmem_page(vma, addr, page, vma->vm_page_prot);
-EXPORT_SYMBOL(vm_insert_page);
+EXPORT_SYMBOL(vm_insert_kmem_page);

What on earth are you trying to do?


WARNING: multiple messages have this Message-ID (diff)
From: Matthew Wilcox <willy@infradead.org>
To: Souptick Joarder <jrdr.linux@gmail.com>
Cc: mark.rutland@arm.com, kstewart@linuxfoundation.org,
	mhocko@suse.com, heiko@sntech.de, airlied@linux.ie,
	linux@dominikbrodowski.net, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, cpandya@codeaurora.org,
	linux1394-devel@lists.sourceforge.net, m.szyprowski@samsung.com,
	ak@linux.intel.com, minchan@kernel.org,
	linux-rockchip@lists.infradead.org, linux@armlinux.org.uk,
	peterz@infradead.org, linux-arm-kernel@lists.infradead.org,
	ying.huang@intel.com, tchibo@google.com, aryabinin@virtuozzo.com,
	treding@nvidia.com, riel@redhat.com, keescook@chromium.org,
	arnd@arndb.de, rppt@linux.vnet.ibm.com,
	dri-devel@lists.freedesktop.org, dan.j.williams@intel.com,
	akpm@linux-foundation.org, dvyukov@google.com, robin@protonic.nl,
	hjc@rock-chips.com, miguel.ojeda.sandonis@gmail.com,
	mcgrof@kernel.org, stefanr@s5r6.in-berlin.de, hannes@cmpxchg.org,
	joe@perches.com, iamjoonsoo.kim@lge.comro
Subject: Re: [PATCH v2] mm: Introduce new function vm_insert_kmem_page
Date: Wed, 3 Oct 2018 13:00:03 -0700	[thread overview]
Message-ID: <20181003200003.GA9965@bombadil.infradead.org> (raw)
In-Reply-To: <20181003185854.GA1174@jordon-HP-15-Notebook-PC>

On Thu, Oct 04, 2018 at 12:28:54AM +0530, Souptick Joarder wrote:
> These are the approaches which could have been taken to handle
> this scenario -
> 
> *  Replace vm_insert_page with vmf_insert_page and then write few
>    extra lines of code to convert VM_FAULT_CODE to errno which
>    makes driver users more complex ( also the reverse mapping errno to
>    VM_FAULT_CODE have been cleaned up as part of vm_fault_t migration ,
>    not preferred to introduce anything similar again)
> 
> *  Maintain both vm_insert_page and vmf_insert_page and use it in
>    respective places. But it won't gurantee that vm_insert_page will
>    never be used in #PF context.
> 
> *  Introduce a similar API like vm_insert_page, convert all non #PF
>    consumer to use it and finally remove vm_insert_page by converting
>    it to vmf_insert_page.
> 
> And the 3rd approach was taken by introducing vm_insert_kmem_page().
> 
> In short, vmf_insert_page will be used in page fault handlers
> context and vm_insert_kmem_page will be used to map kernel
> memory to user vma outside page fault handlers context.

As far as I can tell, vm_insert_kmem_page() is line-for-line identical
with vm_insert_page().  Seriously, here's a diff I just did:

-static int insert_page(struct vm_area_struct *vma, unsigned long addr,
-                       struct page *page, pgprot_t prot)
+static int insert_kmem_page(struct vm_area_struct *vma, unsigned long addr,
+               struct page *page, pgprot_t prot)
-       /* Ok, finally just insert the thing.. */
-int vm_insert_page(struct vm_area_struct *vma, unsigned long addr,
+int vm_insert_kmem_page(struct vm_area_struct *vma, unsigned long addr,
-       return insert_page(vma, addr, page, vma->vm_page_prot);
+       return insert_kmem_page(vma, addr, page, vma->vm_page_prot);
-EXPORT_SYMBOL(vm_insert_page);
+EXPORT_SYMBOL(vm_insert_kmem_page);

What on earth are you trying to do?

WARNING: multiple messages have this Message-ID (diff)
From: willy@infradead.org (Matthew Wilcox)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] mm: Introduce new function vm_insert_kmem_page
Date: Wed, 3 Oct 2018 13:00:03 -0700	[thread overview]
Message-ID: <20181003200003.GA9965@bombadil.infradead.org> (raw)
In-Reply-To: <20181003185854.GA1174@jordon-HP-15-Notebook-PC>

On Thu, Oct 04, 2018 at 12:28:54AM +0530, Souptick Joarder wrote:
> These are the approaches which could have been taken to handle
> this scenario -
> 
> *  Replace vm_insert_page with vmf_insert_page and then write few
>    extra lines of code to convert VM_FAULT_CODE to errno which
>    makes driver users more complex ( also the reverse mapping errno to
>    VM_FAULT_CODE have been cleaned up as part of vm_fault_t migration ,
>    not preferred to introduce anything similar again)
> 
> *  Maintain both vm_insert_page and vmf_insert_page and use it in
>    respective places. But it won't gurantee that vm_insert_page will
>    never be used in #PF context.
> 
> *  Introduce a similar API like vm_insert_page, convert all non #PF
>    consumer to use it and finally remove vm_insert_page by converting
>    it to vmf_insert_page.
> 
> And the 3rd approach was taken by introducing vm_insert_kmem_page().
> 
> In short, vmf_insert_page will be used in page fault handlers
> context and vm_insert_kmem_page will be used to map kernel
> memory to user vma outside page fault handlers context.

As far as I can tell, vm_insert_kmem_page() is line-for-line identical
with vm_insert_page().  Seriously, here's a diff I just did:

-static int insert_page(struct vm_area_struct *vma, unsigned long addr,
-                       struct page *page, pgprot_t prot)
+static int insert_kmem_page(struct vm_area_struct *vma, unsigned long addr,
+               struct page *page, pgprot_t prot)
-       /* Ok, finally just insert the thing.. */
-int vm_insert_page(struct vm_area_struct *vma, unsigned long addr,
+int vm_insert_kmem_page(struct vm_area_struct *vma, unsigned long addr,
-       return insert_page(vma, addr, page, vma->vm_page_prot);
+       return insert_kmem_page(vma, addr, page, vma->vm_page_prot);
-EXPORT_SYMBOL(vm_insert_page);
+EXPORT_SYMBOL(vm_insert_kmem_page);

What on earth are you trying to do?

  parent reply	other threads:[~2018-10-03 20:00 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-03 18:58 [PATCH v2] mm: Introduce new function vm_insert_kmem_page Souptick Joarder
2018-10-03 18:58 ` Souptick Joarder
2018-10-03 19:58 ` Miguel Ojeda
2018-10-03 19:58   ` Miguel Ojeda
2018-10-03 19:58   ` Miguel Ojeda
2018-10-04 11:56   ` Souptick Joarder
2018-10-04 11:56     ` Souptick Joarder
2018-10-04 11:56     ` Souptick Joarder
2018-10-03 20:00 ` Matthew Wilcox [this message]
2018-10-03 20:00   ` Matthew Wilcox
2018-10-03 20:00   ` Matthew Wilcox
2018-10-03 22:14   ` Russell King - ARM Linux
2018-10-03 22:14     ` Russell King - ARM Linux
2018-10-03 22:14     ` Russell King - ARM Linux
2018-10-04  0:39     ` Matthew Wilcox
2018-10-04  0:39       ` Matthew Wilcox
2018-10-04  0:39       ` Matthew Wilcox
2018-10-04 12:15     ` Souptick Joarder
2018-10-04 12:15       ` Souptick Joarder
2018-10-04 12:15       ` Souptick Joarder
2018-10-04 12:34       ` Russell King - ARM Linux
2018-10-04 12:34         ` Russell King - ARM Linux
2018-10-04 12:34         ` Russell King - ARM Linux
2018-10-04 12:34         ` Russell King - ARM Linux
2018-10-04 12:34         ` Russell King - ARM Linux
2018-10-04 18:12         ` Souptick Joarder
2018-10-04 18:12           ` Souptick Joarder
2018-10-04 18:12           ` Souptick Joarder
2018-10-04 18:17           ` Matthew Wilcox
2018-10-04 18:17             ` Matthew Wilcox
2018-10-04 18:17             ` Matthew Wilcox
2018-10-04 18:53             ` Souptick Joarder
2018-10-04 18:53               ` Souptick Joarder
2018-10-04 18:53               ` Souptick Joarder
2018-10-04 19:46               ` Miguel Ojeda
2018-10-04 19:46                 ` Miguel Ojeda
2018-10-04 19:46                 ` Miguel Ojeda
2018-10-05  5:50                 ` Souptick Joarder
2018-10-05  5:50                   ` Souptick Joarder
2018-10-05  5:50                   ` Souptick Joarder
2018-10-05  8:52                   ` Miguel Ojeda
2018-10-05  8:52                     ` Miguel Ojeda
2018-10-05  8:52                     ` Miguel Ojeda
2018-10-05 10:01                     ` Souptick Joarder
2018-10-05 10:01                       ` Souptick Joarder
2018-10-05 10:01                       ` Souptick Joarder
2018-10-05 10:49                       ` Miguel Ojeda
2018-10-05 10:49                         ` Miguel Ojeda
2018-10-05 10:49                         ` Miguel Ojeda
2018-10-05 12:11                         ` Souptick Joarder
2018-10-05 12:11                           ` Souptick Joarder
2018-10-05 12:11                           ` Souptick Joarder
2018-10-05 18:09                           ` Miguel Ojeda
2018-10-05 18:09                             ` Miguel Ojeda
2018-10-05 18:09                             ` Miguel Ojeda
2018-10-06  5:14                             ` Souptick Joarder
2018-10-06  5:14                               ` Souptick Joarder
2018-10-06  5:14                               ` Souptick Joarder
2018-10-06 10:49                               ` Miguel Ojeda
2018-10-06 10:49                                 ` Miguel Ojeda
2018-10-06 10:49                                 ` Miguel Ojeda
2018-10-23 12:14                                 ` Souptick Joarder
2018-10-23 12:14                                   ` Souptick Joarder
2018-10-23 12:14                                   ` Souptick Joarder
2018-10-23 12:24                                   ` Matthew Wilcox
2018-10-23 12:24                                     ` Matthew Wilcox
2018-10-23 12:24                                     ` Matthew Wilcox
2018-10-23 12:33                                     ` Souptick Joarder
2018-10-23 12:33                                       ` Souptick Joarder
2018-10-23 12:33                                       ` Souptick Joarder
2018-10-23 12:59                                       ` Matthew Wilcox
2018-10-23 12:59                                         ` Matthew Wilcox
2018-10-23 12:59                                         ` Matthew Wilcox
2018-10-23 13:15                                         ` Souptick Joarder
2018-10-23 13:15                                           ` Souptick Joarder
2018-10-23 13:15                                           ` Souptick Joarder
2018-10-04 18:21   ` Souptick Joarder
2018-10-04 18:21     ` Souptick Joarder
2018-10-04 18:21     ` Souptick Joarder

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=20181003200003.GA9965@bombadil.infradead.org \
    --to=willy@infradead.org \
    --cc=airlied@linux.ie \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=aryabinin@virtuozzo.com \
    --cc=cpandya@codeaurora.org \
    --cc=dan.j.williams@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=dvyukov@google.com \
    --cc=hannes@cmpxchg.org \
    --cc=heiko@sntech.de \
    --cc=hjc@rock-chips.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=joe@perches.com \
    --cc=jrdr.linux@gmail.com \
    --cc=keescook@chromium.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kstewart@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux1394-devel@lists.sourceforge.net \
    --cc=linux@armlinux.org.uk \
    --cc=linux@dominikbrodowski.net \
    --cc=m.szyprowski@samsung.com \
    --cc=mark.rutland@arm.com \
    --cc=mcgrof@kernel.org \
    --cc=mhocko@suse.com \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=minchan@kernel.org \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    --cc=robin.murphy@arm.com \
    --cc=robin@protonic.nl \
    --cc=rppt@linux.vnet.ibm.com \
    --cc=stefanr@s5r6.in-berlin.de \
    --cc=tchibo@google.com \
    --cc=treding@nvidia.com \
    --cc=ying.huang@intel.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 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.