From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8BF48C47082 for ; Thu, 3 Jun 2021 12:37:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 744D7613E9 for ; Thu, 3 Jun 2021 12:37:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230247AbhFCMin (ORCPT ); Thu, 3 Jun 2021 08:38:43 -0400 Received: from mga06.intel.com ([134.134.136.31]:55086 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229966AbhFCMim (ORCPT ); Thu, 3 Jun 2021 08:38:42 -0400 IronPort-SDR: hSf7E9petHXXdovaPsOnzPGHbntXlZz795wFr9gkckrkAC0hWw98hRA1cy7lLzzBuJd1dHOUHO 0UNvcRT9K9kg== X-IronPort-AV: E=McAfee;i="6200,9189,10003"; a="265204211" X-IronPort-AV: E=Sophos;i="5.83,244,1616482800"; d="scan'208";a="265204211" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Jun 2021 05:36:55 -0700 IronPort-SDR: DMsT4IunyzTkMTPF0j+HWuKSdADAefIJviCOAMI8H+DVHk0IbyopR6+wX1W0nFTnGGRm62w+1Y H1wyY/+b4K/Q== X-IronPort-AV: E=Sophos;i="5.83,244,1616482800"; d="scan'208";a="550676961" Received: from akleen-mobl1.amr.corp.intel.com (HELO [10.209.7.237]) ([10.209.7.237]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Jun 2021 05:36:54 -0700 Subject: Re: [PATCH v1 6/8] dma: Add return value to dma_unmap_page To: Robin Murphy , mst@redhat.com Cc: jasowang@redhat.com, virtualization@lists.linux-foundation.org, hch@lst.de, m.szyprowski@samsung.com, iommu@lists.linux-foundation.org, x86@kernel.org, sathyanarayanan.kuppuswamy@linux.intel.com, jpoimboe@redhat.com, linux-kernel@vger.kernel.org References: <20210603004133.4079390-1-ak@linux.intel.com> <20210603004133.4079390-7-ak@linux.intel.com> From: Andi Kleen Message-ID: Date: Thu, 3 Jun 2021 05:36:53 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > What it looks like to me is abusing SWIOTLB's internal housekeeping to > keep track of virtio-specific state. The DMA API does not attempt to > validate calls in general since in many cases the additional overhead > would be prohibitive. It has always been callers' responsibility to > keep track of what they mapped and make sure sync/unmap calls match, > and there are many, many, subtle and not-so-subtle ways for things to > go wrong if they don't. If virtio is not doing a good enough job of > that, what's the justification for making it the DMA API's problem? In this case it's not prohibitive at all. Just adding a few error returns, and checking the overlap (which seems to have been already solved anyways) I would argue the error returns are good practice anyways, so that API users can check that something bad happening and abort.  The DMA API was never very good at proper error handling, but there's no reason at all to continue being bad it forever. AFAIK the rest just works anyways, so it's not really a new problem to be solved. > >> A new callback is used to avoid changing all the IOMMU drivers. > > Nit: presumably by "IOMMU drivers" you actually mean arch DMA API > backends? Yes > >  Furthermore, AFAICS it's still not going to help against exfiltrating > guest memory by over-unmapping the original SWIOTLB slot *without* > going past the end of the whole buffer, That would be just exfiltrating data that is already shared, unless I'm misunderstanding you. -Andi