From patchwork Tue Mar 19 02:22:08 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Souptick Joarder X-Patchwork-Id: 10858717 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 2CDDE17E9 for ; Tue, 19 Mar 2019 02:19:57 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 108D829452 for ; Tue, 19 Mar 2019 02:19:57 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 046302946D; Tue, 19 Mar 2019 02:19:57 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.0 required=2.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 8F3F129453 for ; Tue, 19 Mar 2019 02:19:56 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1h64Jv-0005xO-Ky; Tue, 19 Mar 2019 02:17:39 +0000 Received: from us1-rack-dfw2.inumbo.com ([104.130.134.6]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1h64Ju-0005xJ-J3 for xen-devel@lists.xen.org; Tue, 19 Mar 2019 02:17:38 +0000 X-Inumbo-ID: 291b3754-49ed-11e9-bc90-bc764e045a96 Received: from mail-pg1-x543.google.com (unknown [2607:f8b0:4864:20::543]) by us1-rack-dfw2.inumbo.com (Halon) with ESMTPS id 291b3754-49ed-11e9-bc90-bc764e045a96; Tue, 19 Mar 2019 02:17:36 +0000 (UTC) Received: by mail-pg1-x543.google.com with SMTP id i7so9518485pgq.0 for ; Mon, 18 Mar 2019 19:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :user-agent; bh=ybJ6FRmizCH+Ysla/KYM0KU4CJcaZTaDUg0Dc25IXgc=; b=TFLM18uvjK4LjZZrue8Bkuk/wUFod454FjOxaVkU6fvE8wKqIIyWS9uODPgL0b6/vX 5tBh0Q/Xv8xN8YraSLbsAoX/qx9KBTuUWtlAiZCC9XFHCWq13RFni5tqM7iEkFUg5JQD 7dxD9m/GNXj/wsPUBEDK9fUxTfOnTKg3AKutKQrbzjD+c/244ovKdJSnQf5qxs7N+xgQ +xQPNs1yG3Md8O/rSUGYjD7ppbTFVRex7asYga3WHKjxFSWKynOL6Is/7zNQAep6NJr8 Lu6SV6uWaG9wLs2QQHz9r2GdPg+2XXKF6nLfc1jePY8hEXmInBOg/0Er7mP2SCb6/iYz E7NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:user-agent; bh=ybJ6FRmizCH+Ysla/KYM0KU4CJcaZTaDUg0Dc25IXgc=; b=BSaySbGx0avHR1sQDW8kawMSQpuZmpyid4D3U2C9DoOPWZNmIRWX2jAkUK6UiALtjA VjmFBd11sPkSo3q01zffFZQu9nsOwU+LHpLuwtrL2tp+7W5icY8x7cgXC7wqlSmC2dxo YtWMaDgsFXBIKp2g1ZDEVVQQsrMSkMrrl1c5PrSKD9pL//sLzSvciVYORvzGIPn3SOiW xSm1od6nTyDeXm7aCBRFe531uSO4JQ5BETGGV8+Cz0JCgSViyCQQgE/HY5UX7yHCv2eZ /OSMd5dnzzHrmKzV6jGkWwOeFZ5WuWPgPhf0o5cdz3vDXS4F+x/AygWjhfMZCnx+Ued9 O61Q== X-Gm-Message-State: APjAAAWzt2Q8Z2oksHMnsP+RDzDX+iNi3Lo4UABsQ5YePYcb5785ftuI 5bmr7Nlcpg8+WhZR2woziSg= X-Google-Smtp-Source: APXvYqwDKhWRiy9D5bbmTHs3dACkLmoUcPuxvlF0bXWwoogDZxk/mizWJx+ooPXJSq6wCKPJbrPmBw== X-Received: by 2002:a65:4608:: with SMTP id v8mr21025819pgq.9.1552961855318; Mon, 18 Mar 2019 19:17:35 -0700 (PDT) Received: from jordon-HP-15-Notebook-PC ([106.51.22.39]) by smtp.gmail.com with ESMTPSA id w68sm1506149pfb.176.2019.03.18.19.17.32 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 18 Mar 2019 19:17:33 -0700 (PDT) Date: Tue, 19 Mar 2019 07:52:08 +0530 From: Souptick Joarder To: akpm@linux-foundation.org, willy@infradead.org, mhocko@suse.com, kirill.shutemov@linux.intel.com, vbabka@suse.cz, riel@surriel.com, sfr@canb.auug.org.au, rppt@linux.vnet.ibm.com, peterz@infradead.org, linux@armlinux.org.uk, robin.murphy@arm.com, iamjoonsoo.kim@lge.com, treding@nvidia.com, keescook@chromium.org, m.szyprowski@samsung.com, stefanr@s5r6.in-berlin.de, hjc@rock-chips.com, heiko@sntech.de, airlied@linux.ie, oleksandr_andrushchenko@epam.com, joro@8bytes.org, pawel@osciak.com, kyungmin.park@samsung.com, mchehab@kernel.org, boris.ostrovsky@oracle.com, jgross@suse.com Message-ID: MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [Xen-devel] [RESEND PATCH v4 0/9] mm: Use vm_map_pages() and vm_map_pages_zero() API X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, xen-devel@lists.xen.org, linux-mm@kvack.org, iommu@lists.linux-foundation.org, linux1394-devel@lists.sourceforge.net, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP Previouly drivers have their own way of mapping range of kernel pages/memory into user vma and this was done by invoking vm_insert_page() within a loop. As this pattern is common across different drivers, it can be generalized by creating new functions and use it across the drivers. vm_map_pages() is the API which could be used to map kernel memory/pages in drivers which has considered vm_pgoff. vm_map_pages_zero() is the API which could be used to map range of kernel memory/pages in drivers which has not considered vm_pgoff. vm_pgoff is passed default as 0 for those drivers. We _could_ then at a later "fix" these drivers which are using vm_map_pages_zero() to behave according to the normal vm_pgoff offsetting simply by removing the _zero suffix on the function name and if that causes regressions, it gives us an easy way to revert. Tested on Rockchip hardware and display is working fine, including talking to Lima via prime. v1 -> v2: Few Reviewed-by. Updated the change log in [8/9] In [7/9], vm_pgoff is treated in V4L2 API as a 'cookie' to select a buffer, not as a in-buffer offset by design and it always want to mmap a whole buffer from its beginning. Added additional changes after discussing with Marek and vm_map_pages() could be used instead of vm_map_pages_zero(). v2 -> v3: Corrected the documentation as per review comment. As suggested in v2, renaming the interfaces to - *vm_insert_range() -> vm_map_pages()* and *vm_insert_range_buggy() -> vm_map_pages_zero()*. As the interface is renamed, modified the code accordingly, updated the change logs and modified the subject lines to use the new interfaces. There is no other change apart from renaming and using the new interface. Patch[1/9] & [4/9], Tested on Rockchip hardware. v3 -> v4: Fixed build warnings on patch [8/9] reported by kbuild test robot. Souptick Joarder (9): mm: Introduce new vm_map_pages() and vm_map_pages_zero() API arm: mm: dma-mapping: Convert to use vm_map_pages() drivers/firewire/core-iso.c: Convert to use vm_map_pages_zero() drm/rockchip/rockchip_drm_gem.c: Convert to use vm_map_pages() drm/xen/xen_drm_front_gem.c: Convert to use vm_map_pages() iommu/dma-iommu.c: Convert to use vm_map_pages() videobuf2/videobuf2-dma-sg.c: Convert to use vm_map_pages() xen/gntdev.c: Convert to use vm_map_pages() xen/privcmd-buf.c: Convert to use vm_map_pages_zero() arch/arm/mm/dma-mapping.c | 22 ++---- drivers/firewire/core-iso.c | 15 +--- drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 17 +---- drivers/gpu/drm/xen/xen_drm_front_gem.c | 18 ++--- drivers/iommu/dma-iommu.c | 12 +--- drivers/media/common/videobuf2/videobuf2-core.c | 7 ++ .../media/common/videobuf2/videobuf2-dma-contig.c | 6 -- drivers/media/common/videobuf2/videobuf2-dma-sg.c | 22 ++---- drivers/xen/gntdev.c | 11 ++- drivers/xen/privcmd-buf.c | 8 +-- include/linux/mm.h | 4 ++ mm/memory.c | 81 ++++++++++++++++++++++ mm/nommu.c | 14 ++++ 13 files changed, 134 insertions(+), 103 deletions(-)