All of lore.kernel.org
 help / color / mirror / Atom feed
From: Souptick Joarder <jrdr.linux@gmail.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>,
	Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
	robin@protonic.nl, stefanr@s5r6.in-berlin.de, hjc@rock-chips.com,
	Heiko Stuebner <heiko@sntech.de>,
	airlied@linux.ie, robin.murphy@arm.com, iamjoonsoo.kim@lge.com,
	Andrew Morton <akpm@linux-foundation.org>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Kees Cook <keescook@chromium.org>,
	treding@nvidia.com, Michal Hocko <mhocko@suse.com>,
	Dan Williams <dan.j.williams@intel.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Mark Rutland <mark.rutland@arm.com>,
	aryabinin@virtuozzo.com, Dmitry Vyukov <dvyukov@google.com>,
	Kate Stewart <kstewart@linuxfoundation.org>,
	tchibo@google.com, riel@redhat.com,
	Minchan Kim <minchan@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	"Huang, Ying" <ying.huang@intel.com>,
	ak@linux.intel.com, rppt@linux.vnet.ibm.com,
	linux@dominikbrodowski.net, Arnd Bergmann <arnd@arndb.de>,
	cpandya@codeaurora.org, hannes@cmpxchg.org,
	Joe Perches <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 <linux-mm@kvack.org>
Subject: Re: [PATCH v2] mm: Introduce new function vm_insert_kmem_page
Date: Thu, 4 Oct 2018 23:51:12 +0530	[thread overview]
Message-ID: <CAFqt6za_OxXArRQfzK1h3L1o+TgU+Xz02gLy2yp0rxAJfFwnqA@mail.gmail.com> (raw)
In-Reply-To: <20181003200003.GA9965@bombadil.infradead.org>

Hi Matthew,

On Thu, Oct 4, 2018 at 1:30 AM Matthew Wilcox <willy@infradead.org> wrote:
>
> 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?

Shall I take below approach rather than just creating a identical API
same as vm_insert_page ??

1. create a wrapper function vm_insert_kmem_page using vm_insert_page.
2. Convert all the non #PF users to use it.
3. Then make vm_insert_page static and convert inline vmf_insert_page to caller.

In that way we will be having two functions vmf_insert_page (#PF) and
vm_insert_kmem_page (non #PF) and both will be using common vm_insert_page
which will be static.

I am clear with the problem statement but not very clear on my solution.

WARNING: multiple messages have this Message-ID (diff)
From: Souptick Joarder <jrdr.linux@gmail.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>,
	Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
	robin@protonic.nl, stefanr@s5r6.in-berlin.de, hjc@rock-chips.com,
	Heiko Stuebner <heiko@sntech.de>,
	airlied@linux.ie, robin.murphy@arm.com, iamjoonsoo.kim@lge.com,
	Andrew Morton <akpm@linux-foundation.org>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Kees Cook <keescook@chromium.org>,
	treding@nvidia.com, Michal Hocko <mhocko@suse.com>,
	Dan Williams <dan.j.williams@intel.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Mark Rutland <mark.rutland@arm.com>,
	aryabinin@virtuozzo.com, Dmitry Vyukov <dvyukov@google.com>,
	Kate Stewart <kstewart@linuxfoundation.org>,
	tchibo@google.com, riel@redhat.com,
	Minchan Kim <minchan@kernel.org>, Peter Zijlstra <peterz@infrad>
Subject: Re: [PATCH v2] mm: Introduce new function vm_insert_kmem_page
Date: Thu, 4 Oct 2018 23:51:12 +0530	[thread overview]
Message-ID: <CAFqt6za_OxXArRQfzK1h3L1o+TgU+Xz02gLy2yp0rxAJfFwnqA@mail.gmail.com> (raw)
In-Reply-To: <20181003200003.GA9965@bombadil.infradead.org>

Hi Matthew,

On Thu, Oct 4, 2018 at 1:30 AM Matthew Wilcox <willy@infradead.org> wrote:
>
> 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?

Shall I take below approach rather than just creating a identical API
same as vm_insert_page ??

1. create a wrapper function vm_insert_kmem_page using vm_insert_page.
2. Convert all the non #PF users to use it.
3. Then make vm_insert_page static and convert inline vmf_insert_page to caller.

In that way we will be having two functions vmf_insert_page (#PF) and
vm_insert_kmem_page (non #PF) and both will be using common vm_insert_page
which will be static.

I am clear with the problem statement but not very clear on my solution.

WARNING: multiple messages have this Message-ID (diff)
From: jrdr.linux@gmail.com (Souptick Joarder)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] mm: Introduce new function vm_insert_kmem_page
Date: Thu, 4 Oct 2018 23:51:12 +0530	[thread overview]
Message-ID: <CAFqt6za_OxXArRQfzK1h3L1o+TgU+Xz02gLy2yp0rxAJfFwnqA@mail.gmail.com> (raw)
In-Reply-To: <20181003200003.GA9965@bombadil.infradead.org>

Hi Matthew,

On Thu, Oct 4, 2018 at 1:30 AM Matthew Wilcox <willy@infradead.org> wrote:
>
> 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?

Shall I take below approach rather than just creating a identical API
same as vm_insert_page ??

1. create a wrapper function vm_insert_kmem_page using vm_insert_page.
2. Convert all the non #PF users to use it.
3. Then make vm_insert_page static and convert inline vmf_insert_page to caller.

In that way we will be having two functions vmf_insert_page (#PF) and
vm_insert_kmem_page (non #PF) and both will be using common vm_insert_page
which will be static.

I am clear with the problem statement but not very clear on my solution.

  parent reply	other threads:[~2018-10-04 18:18 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
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 [this message]
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=CAFqt6za_OxXArRQfzK1h3L1o+TgU+Xz02gLy2yp0rxAJfFwnqA@mail.gmail.com \
    --to=jrdr.linux@gmail.com \
    --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=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=willy@infradead.org \
    --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.