Received: by 10.223.164.221 with SMTP id h29csp3572708wrb; Wed, 4 Oct 2017 04:20:46 -0700 (PDT) X-Google-Smtp-Source: AOwi7QArlETIAAU/08h6qM7ic4/rZcUX+bgGOu2khllcp9Zco2fr5eCGo8bKHxgBtSryEU1UIrqn X-Received: by 10.101.90.6 with SMTP id y6mr13302794pgs.137.1507116046740; Wed, 04 Oct 2017 04:20:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1507116046; cv=none; d=google.com; s=arc-20160816; b=LQ/21KxMtiMuYGm58/mSODCzEsPY3WiZUi3ea13MEE+oUskSVZvHK11hUu+fhW7gL1 OKjzoV6gJyadhhp1Odq7etQdpPrfyHBxgQyfQXIXkbLTYT6DakkEKoQ5EsssxKU/jZvZ ILV+J1u+7raSFbTx0pDXxm/nfAPfj9AkEAMJ1M9/q00WKcjzCJPl7phibYzzxnpRtb+E y8ZqWV03Elj2SOh5HaNdOptobH3NX/iAJJbc0rx9JEX9WLnsbjxQqiHz3qylsXuhqEiD AGIWwXuqz+aln/zDvdfH2gdhZCKGYTvkH33uvvhWyLjaKltGFCC5pCZHePFqNK2SIDVH ySRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=sgpMbMHveQMoWOkeKzkOVGMricjylcv+ES8c0VOFXss=; b=lOoSEZFk02vdwTm/xJndLbGPO9Y3qQw59kkE36ZeXhyHknUmX9l1SqoOxQC4fMoOM6 6brgYkF0PPjH8lFavWgwaChXn+dFgDJr7uMcZU/NMiyR42EyF2P4ztIeDiISr9dnryFo kofFpFfMTFTgrvrIO8Vuv0hB+RLd8+rGsHwpH9i2ic4PFIDa/+wgZm7ScgDaujvY+ZmN E1sZwhV1wwMLo3rWw1KoMlStFACPO+bt9FfSdkN3bzEdlp7jqJ0no1lIHSam+ib3zOSb +iwy1ReCaiMapAIknZRGbKv3FnRgBp+dEj5wU4f3wQYY/J17iGGrzrrasn63hKbcVAT6 FX4g== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t4si134118pgo.784.2017.10.04.04.20.33; Wed, 04 Oct 2017 04:20:46 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751965AbdJDLSw (ORCPT + 99 others); Wed, 4 Oct 2017 07:18:52 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:59936 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751918AbdJDLSt (ORCPT ); Wed, 4 Oct 2017 07:18:49 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7F4971435; Wed, 4 Oct 2017 04:18:49 -0700 (PDT) Received: from [10.1.210.88] (e110467-lin.cambridge.arm.com [10.1.210.88]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E62283F53D; Wed, 4 Oct 2017 04:18:47 -0700 (PDT) Subject: Re: [PATCH] iommu/vt-d: Fix scatterlist offset handling To: David Woodhouse , joro@8bytes.org Cc: ashok.raj@intel.com, leedom@chelsio.com, Harsh@chelsio.com, herbert@gondor.apana.org.au, iommu@lists.linux-foundation.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org References: <644c3e01654f8bd48d669c36e424959d6ef0e27e.1506607370.git.robin.murphy@arm.com> <1507035334.29211.105.camel@infradead.org> <1507068976.29211.156.camel@infradead.org> From: Robin Murphy Message-ID: <69e5e981-ab16-39d4-87dd-9c6b2b1c926d@arm.com> Date: Wed, 4 Oct 2017 12:18:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1507068976.29211.156.camel@infradead.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/10/17 23:16, David Woodhouse wrote: > On Tue, 2017-10-03 at 19:05 +0100, Robin Murphy wrote: >> >> Now, there are indeed plenty of drivers and subsystems which do work on >> lists of explicitly single pages - anything doing some variant of >> "addr = kmap_atomic(sg_page(sg)) + sg->offset;" is easy to spot - but I >> don't think DMA API implementations are in a position to make any kind >> of assumption; nearly all of them just shut up and handle sg->length >> bytes from sg_phys(sg) without questioning the caller, and I reckon >> that's exactly what they should be doing. > > So what's the point in sg->page in the first place? If even the > *offset* can be greater than page size, it isn't even the *first* page > (as you called it). Why aren't we just using a physical address, > instead of an arbitrary page and an offset from that? To nitpick, "the first of one or more contiguous pages" does not imply "the first page of the buffer" - the buffer just lies *somewhere* within that run of pages. Historically, it looks like page+offset first came about in the 2.5 era to support highmem[1] - note that scatterlist users still only really care about virtual and DMA address, not physical. Sure, it wouldn't be entirely impossible to use phys_addr_t instead, but at this point it would be a massively invasive change, and would make implementations of one DMA API callback a tiny bit simpler at the cost of pushing rather more complexity out to hundreds of other users, some of whom might not even call dma_map_sg(). The fact is, regardless of how much sense it does or doesn't make, a fair amount of scatterlist-mangling code exists that is capable of generating silly offsets, and it's so simple to make sure the DMA API implementations don't care that I'd rather just keep on top of that than go off on a crusade in attempt to wipe out the grey areas. > Can we have *negative* sg->offset too? :) unsigned int offset; I'm gonna say no ;) Robin. [1]:https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/tree/include/asm-i386/scatterlist.h?h=v2.5.0 From 1580278521340246074@xxx Tue Oct 03 22:50:38 +0000 2017 X-GM-THRID: 1579793157804914964 X-Gmail-Labels: Inbox,Category Forums