Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754878AbbBJWQi (ORCPT ); Tue, 10 Feb 2015 17:16:38 -0500 Received: from gloria.sntech.de ([95.129.55.99]:45843 "EHLO gloria.sntech.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753047AbbBJWQh (ORCPT ); Tue, 10 Feb 2015 17:16:37 -0500 From: Heiko =?ISO-8859-1?Q?St=FCbner?= To: Tomasz Figa Cc: iommu@lists.linux-foundation.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org, Joerg Roedel , Daniel Kurtz Subject: Re: [PATCH] CHROMIUM: iommu: rockchip: Make sure that page table state is coherent Date: Tue, 10 Feb 2015 23:21:55 +0100 Message-ID: <1697393.usElVkPJfb@diego> User-Agent: KMail/4.14.1 (Linux/3.16-3-amd64; KDE/4.14.2; x86_64; ; ) In-Reply-To: <1423480761-33453-1-git-send-email-tfiga@chromium.org> References: <1423480761-33453-1-git-send-email-tfiga@chromium.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1497 Lines: 31 Am Montag, 9. Februar 2015, 20:19:21 schrieb Tomasz Figa: > Even though the code uses the dt_lock spin lock to serialize mapping > operation from different threads, it does not protect from IOMMU > accesses that might be already taking place and thus altering state > of the IOTLB. This means that current mapping code which first zaps > the page table and only then updates it with new mapping which is > prone to mentioned race. > > In addition, current code assumes that mappings are always > 4 MiB > (which translates to 1024 PTEs) and so they would always occupy > entire page tables. This is not true for mappings created by V4L2 > Videobuf2 DMA contig allocator. > > This patch changes the mapping code to always zap the page table > after it is updated, which avoids the aforementioned race and also > zap the last page of the mapping to make sure that stale data is > not cached from an already existing mapping. > > Signed-off-by: Tomasz Figa > Reviewed-by: Daniel Kurtz I don't know enough about iommu-magic yet to review this properly, but on my rk3288-firefly the whole display pipeline stays in working condition, down to x11 and es2gears, so Tested-by: Heiko Stuebner -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/