From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f198.google.com (mail-lj1-f198.google.com [209.85.208.198]) by kanga.kvack.org (Postfix) with ESMTP id 8C2058E0001 for ; Fri, 28 Sep 2018 08:27:32 -0400 (EDT) Received: by mail-lj1-f198.google.com with SMTP id e12-v6so1724014ljk.3 for ; Fri, 28 Sep 2018 05:27:32 -0700 (PDT) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id k16-v6sor3025556ljc.38.2018.09.28.05.27.30 for (Google Transport Security); Fri, 28 Sep 2018 05:27:30 -0700 (PDT) MIME-Version: 1.0 References: <20180927175123.GA16367@jordon-HP-15-Notebook-PC> <20180927183236.GJ6278@dhcp22.suse.cz> In-Reply-To: <20180927183236.GJ6278@dhcp22.suse.cz> From: Souptick Joarder Date: Fri, 28 Sep 2018 17:57:17 +0530 Message-ID: Subject: Re: [PATCH] mm: Introduce new function vm_insert_kmem_page Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: Andrew Morton , Dan Williams , "Kirill A. Shutemov" , pasha.tatashin@oracle.com, riel@redhat.com, Matthew Wilcox , Minchan Kim , Peter Zijlstra , "Huang, Ying" , ak@linux.intel.com, rppt@linux.vnet.ibm.com, linux@dominikbrodowski.net, Arnd Bergmann , mcgrof@kernel.org, Linux-MM , linux-kernel@vger.kernel.org On Fri, Sep 28, 2018 at 12:02 AM Michal Hocko wrote: > > On Thu 27-09-18 23:21:23, Souptick Joarder wrote: > > vm_insert_kmem_page is similar to vm_insert_page and will > > be used by drivers to map kernel (kmalloc/vmalloc/pages) > > allocated memory to user vma. > > > > Previously vm_insert_page is used for both page fault > > handlers and outside page fault handlers context. When > > vm_insert_page is used in page fault handlers context, > > each driver have to map errno to VM_FAULT_CODE in their > > own way. But as part of vm_fault_t migration all the > > page fault handlers are cleaned up by using new vmf_insert_page. > > Going forward, vm_insert_page will be removed by converting > > it to vmf_insert_page. > > > > But their are places where vm_insert_page is used outside > > page fault handlers context and converting those to > > vmf_insert_page is not a good approach as drivers will end > > up with new VM_FAULT_CODE to errno conversion code and it will > > make each user more complex. > > > > So this new vm_insert_kmem_page can be used to map kernel > > memory to user vma outside page fault handler context. > > > > 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. > > > > We will slowly convert all the user of vm_insert_page to > > vm_insert_kmem_page after this API be available in linus tree. > > In general I do not like patches adding a new exports/functionality > without any user added at the same time. I am not going to look at the > implementation right now but the above opens more questions than it > gives answers. Why do we have to distinguish #PF from other paths? Going forward, the plan is to restrict future drivers not to use vm_insert_page ( *it will generate new errno to VM_FAULT_CODE mapping code for new drivers which were already cleaned up for existing drivers*) in #PF context but to make use of vmf_insert_page which returns VMF_FAULT_CODE and that is not possible until both vm_insert_page and vmf_insert_page API exists. But there are some consumers of vm_insert_page which use it outside #PF context. straight forward conversion of vm_insert_page to vmf_insert_page won't work there as those function calls expects errno not vm_fault_t in return. e.g - drivers/auxdisplay/cfag12864bfb.c, line 55 drivers/auxdisplay/ht16k33.c, line 227 drivers/firewire/core-iso.c, line 115 drivers/gpu/drm/rockchip/rockchip_drm_gem.c, line 237 drivers/gpu/drm/xen/xen_drm_front_gem.c, line 253 drivers/iommu/dma-iommu.c, line 600 drivers/media/common/videobuf2/videobuf2-dma-sg.c, line 343 drivers/media/usb/usbvision/usbvision-video.c, line 1056 drivers/xen/gntalloc.c, line 548 drivers/xen/gntdev.c, line 1149 drivers/xen/privcmd-buf.c, line 184 mm/vmalloc.c, line 2254 net/ipv4/tcp.c, line 1806 net/packet/af_packet.c, line 4407 These are the approaches which could have been taken to handle this scenario - 1. 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) 2. 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. 3. 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().