Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp2536763imm; Thu, 18 Oct 2018 16:53:23 -0700 (PDT) X-Google-Smtp-Source: ACcGV62JS7lKIz1GbJdb5pZsauzr5M5Q5Tw+6Sg3nKR4gSu7KmxLjg23LP+PzZq4uV0T/qD30RXt X-Received: by 2002:a62:1693:: with SMTP id 141-v6mr24249740pfw.183.1539906803257; Thu, 18 Oct 2018 16:53:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539906803; cv=none; d=google.com; s=arc-20160816; b=V5WMLqKDZITGtDMomn5mKxPlF0jym+lGOT21+QecF9tpXro2mHfQ593YRIoZBJegdP 5IB3omwIK2swwMrdZo5tJOWoaF4AHsxZJ7VYweUYAJhlYsZ2+/XVSQVQWt5Q+xy0dOtJ wzNaRrWuvPvZMho+cTwefAXbPlHRWkjFJ8fplZamv3ddTqseIt+7h2RF3F0pZ6W+tj/l 5RihR3PGKtXCcmk4nVj17HeJpaFqUq7Eq0Nto/B5zknAsKN4kz+r9PGRu0q/2O/RyGim eQUnXQ/74xDAH9KoZc8G0vgX2xw0y6QVnC+kcuQYw0sNm+gEWbi8KC91qxfcvXE0AQZP uSNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=xfo3eqj8a4f5X6bsd+KI4rXWngqYQa4mS+Ipp5Q2lJE=; b=IT1Bu6v61D6f6owz7bQbpggU62CMAOWnDaMHR+kvIHWCrcMhQDupBA3hkND06SUQ4R agfVofPoYSpqrHE3QGB2Jd4eRrHB7/MFGAttX/EwSZAxOTDOq3w4NDdhQEtJAR+c/Q1v xtyNYjMb58ucJj/kawNvL8Zs5jT3oPOs2EOn0sKyTtCntAKQfYyaWJpuFO99o93cN4rF 9O/h7CLmzex4yWf+fUMnuOQv6TkS7xxSR9Vu860szXe6aAtsgIiIZtKg8Halkjxpl0i6 oRdnJEAfyiTYvjN+KH46LbceD091o+UuqIrlfBPdPzJHtFpy5uY9vi7FDmfVIwNF4KkP N/VA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2018-07-02 header.b=pJCn1d1y; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 33-v6si6032655plo.114.2018.10.18.16.53.07; Thu, 18 Oct 2018 16:53:23 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2018-07-02 header.b=pJCn1d1y; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727464AbeJSH4C (ORCPT + 99 others); Fri, 19 Oct 2018 03:56:02 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:47202 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727141AbeJSH4C (ORCPT ); Fri, 19 Oct 2018 03:56:02 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w9INnjMo174668; Thu, 18 Oct 2018 23:52:33 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=corp-2018-07-02; bh=xfo3eqj8a4f5X6bsd+KI4rXWngqYQa4mS+Ipp5Q2lJE=; b=pJCn1d1ysTORdj7vVjG9s90/b+pR6+G1Z5f2hDsy0N6r850TnjC5q3S3Lvnj/jRG8w1b G+it7BxeCOuLt0F/N/Me9JWUAzasCVECVToqXH7mndWs2W9eBn3/tQRgYUwn2vANfshP Ss4TDYKUYo6pw/1Y5IS98iZ6exzJsMheG77mxVL8f4F23zO8AcQPCp4Twlhp2Yufsvlo PBmr0SsEz9144lewkCgoJJePKJBsVIBP430X6cgFRDpBRaEhwaNt61hIqROS1iMCpy7C LlpTat/oAgYzf44CIFOxYyHUveYF2jSZWs0x+4Xl+RwKJsrjRusMsxC4WD+P/yXKBXR4 Rg== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2n384uhm6r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 18 Oct 2018 23:52:33 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w9INqXne024464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 18 Oct 2018 23:52:33 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w9INqWmE000509; Thu, 18 Oct 2018 23:52:33 GMT Received: from konrads-mbp.lan (/209.6.36.129) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Oct 2018 16:52:32 -0700 Date: Thu, 18 Oct 2018 19:52:25 -0400 From: Konrad Rzeszutek Wilk To: Joe Jin Cc: John Sobecki , "DONGLI.ZHANG" , konrad@kernel.org, Christoph Helwig , "xen-devel@lists.xenproject.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH V2] xen-swiotlb: use actually allocated size on check physical continuous Message-ID: <20181018235219.GA36047@konrads-mbp.lan> References: <0453c762-1f8b-079f-5fdf-548e90909318@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0453c762-1f8b-079f-5fdf-548e90909318@oracle.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9050 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=2 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810180199 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 16, 2018 at 03:21:16PM -0700, Joe Jin wrote: > xen_swiotlb_{alloc,free}_coherent() allocate/free memory by order, > but passed required size to range_straddles_page_boundary(), > when first pages are physical continuous, > range_straddles_page_boundary() returned true, then did not > exchanged memory with Xen, later on free memory, it tried to > exchanged non-contiguous memory with Xen, then kernel panic. I have a hard time understanding the commit message. I think you mean to say: xen_swiotlb_{alloc,free}_coherent() allocate/free memory based on the order of the pages and not size argument (bytes). This is inconsistent with range_straddles_page_boundary and memset which use the 'size' value, which may lead to not exchanging memory with Xen (range_straddles_page_boundary() returned true). And then the call to xen_swiotlb_free_coherent() would actually try to exchange the memory with Xen, leading to the kernel hitting an BUG (as the hypercall returned an error). This patch fixes it by making the 'size' variable be of the same size as the amount of memory allocated. I checked it as such.. > > Signed-off-by: Joe Jin > Cc: Konrad Rzeszutek Wilk > Cc: Boris Ostrovsky > Cc: Christoph Helwig > Cc: Dongli Zhang > Cc: John Sobecki > > --- > drivers/xen/swiotlb-xen.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c > index a6f9ba85dc4b..aa081f806728 100644 > --- a/drivers/xen/swiotlb-xen.c > +++ b/drivers/xen/swiotlb-xen.c > @@ -303,6 +303,9 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size, > */ > flags &= ~(__GFP_DMA | __GFP_HIGHMEM); > > + /* Convert the size to actually allocated. */ > + size = 1UL << (order + XEN_PAGE_SHIFT); > + > /* On ARM this function returns an ioremap'ped virtual address for > * which virt_to_phys doesn't return the corresponding physical > * address. In fact on ARM virt_to_phys only works for kernel direct > @@ -351,6 +354,9 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t size, void *vaddr, > * physical address */ > phys = xen_bus_to_phys(dev_addr); > > + /* Convert the size to actually allocated. */ > + size = 1UL << (order + XEN_PAGE_SHIFT); > + > if (((dev_addr + size - 1 <= dma_mask)) || > range_straddles_page_boundary(phys, size)) > xen_destroy_contiguous_region(phys, order); > -- > 2.15.2 (Apple Git-101.1) > >