From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753675AbbITCSv (ORCPT ); Sat, 19 Sep 2015 22:18:51 -0400 Received: from e23smtp01.au.ibm.com ([202.81.31.143]:33175 "EHLO e23smtp01.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752539AbbITCSu (ORCPT ); Sat, 19 Sep 2015 22:18:50 -0400 X-Helo: d23dlp02.au.ibm.com X-MailFrom: weiyang@linux.vnet.ibm.com X-RcptTo: linux-kernel@vger.kernel.org From: Wei Yang To: akinobu.mita@gmail.com, davem@davemloft.net, benh@kernel.crashing.org, paulus@samba.org Cc: linux-kernel@vger.kernel.org, Wei Yang Subject: [RFC PATCH] iommu: enable the last bit in iommu_area_alloc() Date: Sun, 20 Sep 2015 10:14:56 +0800 Message-Id: <1442715296-2649-1-git-send-email-weiyang@linux.vnet.ibm.com> X-Mailer: git-send-email 2.5.0 X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15092002-1618-0000-0000-000002CB95A2 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In 'commit a66022c45775 ("iommu-helper: use bitmap library")', iommu_area_alloc() uses bitmap_find_next_zero_area() to lookup available iommu space. When given "start, size, nr", bitmap_find_next_zero_area() is looking for a range with nr zero bit in [start, size) instead of [start, size]. This means the last bit is already excluded. By decrease size at the beginning, the last iommu page will not be allocated. This patch removes the decrease on size. Signed-off-by: Wei Yang --- I may missed something, while the code makes me a little confused. I found two users of iommu_area_alloc(), one in powernv platform and one in lib/iommu-common.c. The "limit", which is passed to bitmap_find_next_zero_area() as the "size" are both set to pool->end in these two cases. While the pool->end in these two cases are calculated differently. On powernv platform, iommu_init_table() sets p->end = p->start + tbl->poolsize; While in iommu_tbl_pool_init(), pools[i].end = pools[i].start + iommu->poolsize -1; In both case, it will not do harm to system, except we have one more less iommu page in the second case. And then in current code, iommu_area_alloc() will decrease the size by one again. I may missed something, currently I think the implementation in powernv platform is correct while iommu_area_alloc() eats the last iommu page. Tests: I have apply this on top of v4.2 and enforce to use dma_iommu_ops for each device. Transfered on guest image with 4GB by scp and check the checksum are the same. --- lib/iommu-helper.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c index c27e269..2866004 100644 --- a/lib/iommu-helper.c +++ b/lib/iommu-helper.c @@ -23,8 +23,6 @@ unsigned long iommu_area_alloc(unsigned long *map, unsigned long size, { unsigned long index; - /* We don't want the last of the limit */ - size -= 1; again: index = bitmap_find_next_zero_area(map, size, start, nr, align_mask); if (index < size) { -- 2.5.0