From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935850AbdKPVor (ORCPT ); Thu, 16 Nov 2017 16:44:47 -0500 Received: from mga07.intel.com ([134.134.136.100]:38864 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933899AbdKPVok (ORCPT ); Thu, 16 Nov 2017 16:44:40 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.44,405,1505804400"; d="scan'208";a="150264805" Date: Thu, 16 Nov 2017 13:09:33 -0800 From: "Raj, Ashok" To: Alex Williamson Cc: Jacob Pan , leedom@chelsio.com, herbert@gondor.apana.org.au, David Woodhouse , linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, linux-crypto@vger.kernel.org, Harsh@chelsio.com, Ashok Raj Subject: Re: [PATCH] iommu/vt-d: Fix scatterlist offset handling Message-ID: <20171116210933.GA53016@otc-nc-03> References: <644c3e01654f8bd48d669c36e424959d6ef0e27e.1506607370.git.robin.murphy@arm.com> <1507035334.29211.105.camel@infradead.org> <20171006144309.GA30803@8bytes.org> <20171106104709.06b38f7c@jacob-builder> <20171115155456.141a6dc8@jacob-builder> <20171116143244.2583d044@t450s.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171116143244.2583d044@t450s.home> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Alex On Thu, Nov 16, 2017 at 02:32:44PM -0700, Alex Williamson wrote: > On Wed, 15 Nov 2017 15:54:56 -0800 > Jacob Pan wrote: > > > Hi Alex and all, > > > > Just wondering if you could merge Robin's patch for the next rc. From > > all our testing, this seems to be a solid fix and should be included in > > the stable releases as well. > > Hi Jacob, > > Sorry, this wasn't on my radar, I only scanned for patches back through > about when Joerg refreshed his next branch (others on the list speak up > if I didn't pickup your patches for the v4.15 merge window). > > This patch makes sense to me and I'm glad you were able to work through > the anomaly Harsh saw in testing as an unrelated issue, but... > > > What do we do about this? I certainly can't rip out large page support > and put a stable tag on the patch. I'm not really spotting what's > wrong with large page support here, other than the comment about it > being a mess. Suggestions? Thanks, > Largepage seems to work and i don't think we need to rip it out. When Harsh tested it at one point we thought disabling super-page seemed to make the problem go away. Jacob tested and we still saw the need for Robin's patch. Yes, the function looks humongous but i don't think we should wait for that before this merge. Cheers, Ashok