From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Stuebner Subject: Re: [PATCHv2 1/9] mm: Introduce new vm_insert_range and vm_insert_range_buggy API Date: Thu, 31 Jan 2019 13:34:10 +0100 Message-ID: <1572595.mVW1PIlZyR@phil> References: <20190131030812.GA2174@jordon-HP-15-Notebook-PC> <1701923.z6LKAITQJA@phil> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Souptick Joarder , hjc@rock-chips.com Cc: Michal Hocko , Peter Zijlstra , dri-devel@lists.freedesktop.org, Linux-MM , linux1394-devel@lists.sourceforge.net, Stephen Rothwell , oleksandr_andrushchenko@epam.com, Russell King - ARM Linux , Matthew Wilcox , airlied@linux.ie, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-media@vger.kernel.org, pawel@osciak.com, Rik van Riel , iommu@lists.linux-foundation.org, rppt@linux.vnet.ibm.com, Boris Ostrovsky , mchehab@kernel.org, vbabka@suse.cz, Juergen Gross , linux-kernel@vger.kernel.org, xen-devel@lists.xen.org, Kyungmin Park , Andrew Morton , robin.murphy@arm.com, "Kirill A. Shutemov" List-Id: iommu@lists.linux-foundation.org QW0gRG9ubmVyc3RhZywgMzEuIEphbnVhciAyMDE5LCAxMzozMTo1MiBDRVQgc2NocmllYiBTb3Vw dGljayBKb2FyZGVyOgo+IE9uIFRodSwgSmFuIDMxLCAyMDE5IGF0IDU6MzcgUE0gSGVpa28gU3R1 ZWJuZXIgPGhlaWtvQHNudGVjaC5kZT4gd3JvdGU6Cj4gPgo+ID4gQW0gRG9ubmVyc3RhZywgMzEu IEphbnVhciAyMDE5LCAwNDowODoxMiBDRVQgc2NocmllYiBTb3VwdGljayBKb2FyZGVyOgo+ID4g PiBQcmV2aW91bHkgZHJpdmVycyBoYXZlIHRoZWlyIG93biB3YXkgb2YgbWFwcGluZyByYW5nZSBv Zgo+ID4gPiBrZXJuZWwgcGFnZXMvbWVtb3J5IGludG8gdXNlciB2bWEgYW5kIHRoaXMgd2FzIGRv bmUgYnkKPiA+ID4gaW52b2tpbmcgdm1faW5zZXJ0X3BhZ2UoKSB3aXRoaW4gYSBsb29wLgo+ID4g Pgo+ID4gPiBBcyB0aGlzIHBhdHRlcm4gaXMgY29tbW9uIGFjcm9zcyBkaWZmZXJlbnQgZHJpdmVy cywgaXQgY2FuCj4gPiA+IGJlIGdlbmVyYWxpemVkIGJ5IGNyZWF0aW5nIG5ldyBmdW5jdGlvbnMg YW5kIHVzZSBpdCBhY3Jvc3MKPiA+ID4gdGhlIGRyaXZlcnMuCj4gPiA+Cj4gPiA+IHZtX2luc2Vy dF9yYW5nZSgpIGlzIHRoZSBBUEkgd2hpY2ggY291bGQgYmUgdXNlZCB0byBtYXBwZWQKPiA+ID4g a2VybmVsIG1lbW9yeS9wYWdlcyBpbiBkcml2ZXJzIHdoaWNoIGhhcyBjb25zaWRlcmVkIHZtX3Bn b2ZmCj4gPiA+Cj4gPiA+IHZtX2luc2VydF9yYW5nZV9idWdneSgpIGlzIHRoZSBBUEkgd2hpY2gg Y291bGQgYmUgdXNlZCB0byBtYXAKPiA+ID4gcmFuZ2Ugb2Yga2VybmVsIG1lbW9yeS9wYWdlcyBp biBkcml2ZXJzIHdoaWNoIGhhcyBub3QgY29uc2lkZXJlZAo+ID4gPiB2bV9wZ29mZi4gdm1fcGdv ZmYgaXMgcGFzc2VkIGRlZmF1bHQgYXMgMCBmb3IgdGhvc2UgZHJpdmVycy4KPiA+ID4KPiA+ID4g V2UgX2NvdWxkXyB0aGVuIGF0IGEgbGF0ZXIgImZpeCIgdGhlc2UgZHJpdmVycyB3aGljaCBhcmUg dXNpbmcKPiA+ID4gdm1faW5zZXJ0X3JhbmdlX2J1Z2d5KCkgdG8gYmVoYXZlIGFjY29yZGluZyB0 byB0aGUgbm9ybWFsIHZtX3Bnb2ZmCj4gPiA+IG9mZnNldHRpbmcgc2ltcGx5IGJ5IHJlbW92aW5n IHRoZSBfYnVnZ3kgc3VmZml4IG9uIHRoZSBmdW5jdGlvbgo+ID4gPiBuYW1lIGFuZCBpZiB0aGF0 IGNhdXNlcyByZWdyZXNzaW9ucywgaXQgZ2l2ZXMgdXMgYW4gZWFzeSB3YXkgdG8gcmV2ZXJ0Lgo+ ID4gPgo+ID4gPiBTaWduZWQtb2ZmLWJ5OiBTb3VwdGljayBKb2FyZGVyIDxqcmRyLmxpbnV4QGdt YWlsLmNvbT4KPiA+ID4gU3VnZ2VzdGVkLWJ5OiBSdXNzZWxsIEtpbmcgPGxpbnV4QGFybWxpbnV4 Lm9yZy51az4KPiA+ID4gU3VnZ2VzdGVkLWJ5OiBNYXR0aGV3IFdpbGNveCA8d2lsbHlAaW5mcmFk ZWFkLm9yZz4KPiA+Cj4gPiBobW0sIEknbSBtaXNzaW5nIGEgY2hhbmdlbG9nIGhlcmUgYmV0d2Vl biB2MSBhbmQgdjIuCj4gPiBOZXZlcnRoZWxlc3MgSSBtYW5hZ2VkIHRvIHRlc3QgdjEgb24gUm9j a2NoaXAgaGFyZHdhcmUKPiA+IGFuZCBkaXNwbGF5IGlzIHN0aWxsIHdvcmtpbmcsIGluY2x1ZGlu ZyB0YWxraW5nIHRvIExpbWEgdmlhIHByaW1lLgo+ID4KPiA+IFNvIGlmIHRoZXJlIGFyZW4ndCBh bnkgYmlnIGNoYW5nZXMgZm9yIHYyLCBvbiBSb2NrY2hpcAo+ID4gVGVzdGVkLWJ5OiBIZWlrbyBT dHVlYm5lciA8aGVpa29Ac250ZWNoLmRlPgo+IAo+IENoYW5nZSBsb2cgaXMgYXZhaWxhYmxlIGlu IFswLzldLgo+IFBhdGNoIFsxLzldICYgWzQvOV0gaGF2ZSBubyBjaGFuZ2VzIGJldHdlZW4gdjEg LT4gdjIuCgpJIG5ldmVyIHNlZW0gdG8gZ2V0IHlvdXIgY292ZXItbGV0dGVycywgc28gZGlkbid0 IHNlZSB0aGF0LCBzb3JyeS4KCkJ1dCBncmVhdCB0aGF0IHRoZXJlIHdlcmVuJ3QgY2hhbmdlcyB0 aGVuIDotKQoKSGVpa28KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3Rv cC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmkt ZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9873BC169C4 for ; Thu, 31 Jan 2019 12:34:55 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6CE282087F for ; Thu, 31 Jan 2019 12:34:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="h8jc2D3v" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6CE282087F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=sntech.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=g/nD3DZ6lyeL8D7LN1uB7ZfMQS3Kehh6LEcgJ31eNps=; b=h8jc2D3vV/tRjD syYndOPrSRrm8Q3VzNmXSAiUaqdoh+wDm7oVKa5vKMxy/GMJoEg5znDB/2AoTeieMkXLQfwqgjgnV mbdhBaNHXCxFoZedSftxBvSLNPlTee0ymP+sj6nPMnI1qhxhuTlJXN4AgX8nRLZE5u4+QLcRMuDq5 dwr9lBpZrQmL6zEVJkJ9YS3In+MN/EtYmHsetoNDAmNh/SxmAYqx2vEZ616yCSp2wwGhwe0gwsRUX 78WY9VWt8pEPSRybYuF04ijniYfwYzfTQCFUdTKkDADJMbRtU2e3NdIJJ68Wa68ABd2ZryYr6Mg0j XYkwIkXgw3boc9tHfIiQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gpBYU-0007KQ-9N; Thu, 31 Jan 2019 12:34:54 +0000 Received: from gloria.sntech.de ([185.11.138.130]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gpBYR-0007Jz-6N; Thu, 31 Jan 2019 12:34:52 +0000 Received: from wf0848.dip.tu-dresden.de ([141.76.183.80] helo=phil.localnet) by gloria.sntech.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gpBXj-000441-H7; Thu, 31 Jan 2019 13:34:07 +0100 From: Heiko Stuebner To: Souptick Joarder , hjc@rock-chips.com Subject: Re: [PATCHv2 1/9] mm: Introduce new vm_insert_range and vm_insert_range_buggy API Date: Thu, 31 Jan 2019 13:34:10 +0100 Message-ID: <1572595.mVW1PIlZyR@phil> In-Reply-To: References: <20190131030812.GA2174@jordon-HP-15-Notebook-PC> <1701923.z6LKAITQJA@phil> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190131_043451_386355_8FE04E79 X-CRM114-Status: GOOD ( 21.14 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Michal Hocko , Peter Zijlstra , dri-devel@lists.freedesktop.org, Linux-MM , linux1394-devel@lists.sourceforge.net, Stephen Rothwell , oleksandr_andrushchenko@epam.com, joro@8bytes.org, Russell King - ARM Linux , Matthew Wilcox , airlied@linux.ie, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-media@vger.kernel.org, pawel@osciak.com, Rik van Riel , iommu@lists.linux-foundation.org, rppt@linux.vnet.ibm.com, Boris Ostrovsky , mchehab@kernel.org, vbabka@suse.cz, Juergen Gross , linux-kernel@vger.kernel.org, xen-devel@lists.xen.org, Kyungmin Park , Andrew Morton , robin.murphy@arm.com, "Kirill A. Shutemov" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Am Donnerstag, 31. Januar 2019, 13:31:52 CET schrieb Souptick Joarder: > On Thu, Jan 31, 2019 at 5:37 PM Heiko Stuebner wrote: > > > > Am Donnerstag, 31. Januar 2019, 04:08:12 CET schrieb Souptick Joarder: > > > 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_insert_range() is the API which could be used to mapped > > > kernel memory/pages in drivers which has considered vm_pgoff > > > > > > vm_insert_range_buggy() 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_insert_range_buggy() to behave according to the normal vm_pgoff > > > offsetting simply by removing the _buggy suffix on the function > > > name and if that causes regressions, it gives us an easy way to revert. > > > > > > Signed-off-by: Souptick Joarder > > > Suggested-by: Russell King > > > Suggested-by: Matthew Wilcox > > > > hmm, I'm missing a changelog here between v1 and v2. > > Nevertheless I managed to test v1 on Rockchip hardware > > and display is still working, including talking to Lima via prime. > > > > So if there aren't any big changes for v2, on Rockchip > > Tested-by: Heiko Stuebner > > Change log is available in [0/9]. > Patch [1/9] & [4/9] have no changes between v1 -> v2. I never seem to get your cover-letters, so didn't see that, sorry. But great that there weren't changes then :-) Heiko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AF00CC169C4 for ; Thu, 31 Jan 2019 12:35:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8BB482087F for ; Thu, 31 Jan 2019 12:35:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732743AbfAaMfA (ORCPT ); Thu, 31 Jan 2019 07:35:00 -0500 Received: from gloria.sntech.de ([185.11.138.130]:56394 "EHLO gloria.sntech.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726153AbfAaMfA (ORCPT ); Thu, 31 Jan 2019 07:35:00 -0500 Received: from wf0848.dip.tu-dresden.de ([141.76.183.80] helo=phil.localnet) by gloria.sntech.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gpBXj-000441-H7; Thu, 31 Jan 2019 13:34:07 +0100 From: Heiko Stuebner To: Souptick Joarder , hjc@rock-chips.com Cc: Andrew Morton , Matthew Wilcox , Michal Hocko , "Kirill A. Shutemov" , vbabka@suse.cz, Rik van Riel , Stephen Rothwell , rppt@linux.vnet.ibm.com, Peter Zijlstra , Russell King - ARM Linux , robin.murphy@arm.com, airlied@linux.ie, oleksandr_andrushchenko@epam.com, joro@8bytes.org, pawel@osciak.com, Kyungmin Park , mchehab@kernel.org, Boris Ostrovsky , Juergen Gross , linux-kernel@vger.kernel.org, Linux-MM , linux-arm-kernel@lists.infradead.org, linux1394-devel@lists.sourceforge.net, dri-devel@lists.freedesktop.org, linux-rockchip@lists.infradead.org, xen-devel@lists.xen.org, iommu@lists.linux-foundation.org, linux-media@vger.kernel.org Subject: Re: [PATCHv2 1/9] mm: Introduce new vm_insert_range and vm_insert_range_buggy API Date: Thu, 31 Jan 2019 13:34:10 +0100 Message-ID: <1572595.mVW1PIlZyR@phil> In-Reply-To: References: <20190131030812.GA2174@jordon-HP-15-Notebook-PC> <1701923.z6LKAITQJA@phil> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Am Donnerstag, 31. Januar 2019, 13:31:52 CET schrieb Souptick Joarder: > On Thu, Jan 31, 2019 at 5:37 PM Heiko Stuebner wrote: > > > > Am Donnerstag, 31. Januar 2019, 04:08:12 CET schrieb Souptick Joarder: > > > 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_insert_range() is the API which could be used to mapped > > > kernel memory/pages in drivers which has considered vm_pgoff > > > > > > vm_insert_range_buggy() 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_insert_range_buggy() to behave according to the normal vm_pgoff > > > offsetting simply by removing the _buggy suffix on the function > > > name and if that causes regressions, it gives us an easy way to revert. > > > > > > Signed-off-by: Souptick Joarder > > > Suggested-by: Russell King > > > Suggested-by: Matthew Wilcox > > > > hmm, I'm missing a changelog here between v1 and v2. > > Nevertheless I managed to test v1 on Rockchip hardware > > and display is still working, including talking to Lima via prime. > > > > So if there aren't any big changes for v2, on Rockchip > > Tested-by: Heiko Stuebner > > Change log is available in [0/9]. > Patch [1/9] & [4/9] have no changes between v1 -> v2. I never seem to get your cover-letters, so didn't see that, sorry. But great that there weren't changes then :-) Heiko