Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp382313ybk; Fri, 15 May 2020 03:16:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxm4j7C01p57jB/XFn40I+7aIb/TffCWvZn+qivA6UY0oTCYcuvh/cTCj+cFbWDhK/ZQ7Cs X-Received: by 2002:a17:906:560b:: with SMTP id f11mr1848192ejq.264.1589537786490; Fri, 15 May 2020 03:16:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589537786; cv=none; d=google.com; s=arc-20160816; b=j0KcsmPFTlNb60eidqEFf2d7EgAQAT5EZlLkD8kIxyaPtmhadpeW/Zqyp0OjsXW4QY l1wpPMlrUtrYVC392r+Z3joyLn/G+dLW8NN7ysIfDgGGR2yUda5rPuWuwv4SPdBEpoft F9IBc3ZgNe1ZtcSYsdc+NuL+TRL1+Oa/fxKIiBOEhzkqkifssBL7N6y3qNIhLte44eoH 44VHr6HN0WFT8GbeMTuL21jebOspMPizpwv4NANEoRBsffI0giKccs5ztGksJmuFsGXs tEPfQGIPRfdXNRba2kK+h2Er19RmMryBCM4fa7iwwhMHprInj4YKb+IOglcuQH5KccJE zI3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=0MKoWH/rG+jrDQ9BJKMgClfKWi0OU8i02iZINw2Eoiw=; b=Gb2hwWIfV6U4yDG7TtTG/3xrIMHSkdqKcbBZTPxCiOS2DG+87q7DCEbpwvFHMTpjwW 4K12jD74hxvr/8sFoKnFKCRJqUkkVH+ev6grUFpZF0k4vkNoFt7Z3RsF+QPv5CiMDnCA dvAlBj31nCMnkOGNYPV2x27zyksOY8ZQbeubppFxgLWwd/FrXTxGDBw6K6J0NHPH+MPp kg/n+mCYNfHdp1Vd5INWb9HURb1zN3v+xb91UHIy4pjT02YidrEPthIuXnVuH6Km/NVP yyyQWbm+rCPtK5UUPNzfP2av9o13XnTdLHpNFwYLtcIx49r+1Re1X4DcTA84mUUbxfTZ AvsQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=UoncJL2B; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t23si941240eje.111.2020.05.15.03.16.02; Fri, 15 May 2020 03:16:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=UoncJL2B; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728127AbgEOKMd (ORCPT + 99 others); Fri, 15 May 2020 06:12:33 -0400 Received: from us-smtp-2.mimecast.com ([207.211.31.81]:35371 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728083AbgEOKMd (ORCPT ); Fri, 15 May 2020 06:12:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1589537551; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0MKoWH/rG+jrDQ9BJKMgClfKWi0OU8i02iZINw2Eoiw=; b=UoncJL2BiGZmXOHftuvoO0l63bhbcD8Sowd86xuUjqhtGUVI0NbQIjeBd/1te/nQn5DmM9 ty2yCX/c6h2jXn6ismutnCysnYPy91lwz8MgPU2Dh/Qd51olq67N961nNelU/xKtpiFSoK /RsbqazdY72YpghSViPcG1OZBfmDy5o= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-29-FfsBUAj5OSSzyVChPXN-GA-1; Fri, 15 May 2020 06:12:30 -0400 X-MC-Unique: FfsBUAj5OSSzyVChPXN-GA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 01163189952E; Fri, 15 May 2020 10:12:28 +0000 (UTC) Received: from sirius.home.kraxel.org (ovpn-115-145.ams2.redhat.com [10.36.115.145]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0554A26E41; Fri, 15 May 2020 10:12:26 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id EB6CF16E16; Fri, 15 May 2020 12:12:24 +0200 (CEST) Date: Fri, 15 May 2020 12:12:24 +0200 From: Gerd Hoffmann To: Marek Szyprowski Cc: dri-devel@lists.freedesktop.org, iommu@lists.linux-foundation.org, linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org, Christoph Hellwig , Robin Murphy , Bartlomiej Zolnierkiewicz , linux-arm-kernel@lists.infradead.org, David Airlie , Daniel Vetter , virtualization@lists.linux-foundation.org Subject: Re: [PATCH v5 25/38] drm: virtio: fix common struct sg_table related issues Message-ID: <20200515101224.vrr6rlzgwc6d35az@sirius.home.kraxel.org> References: <20200513132114.6046-1-m.szyprowski@samsung.com> <20200513133245.6408-1-m.szyprowski@samsung.com> <20200513133245.6408-25-m.szyprowski@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200513133245.6408-25-m.szyprowski@samsung.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 13, 2020 at 03:32:32PM +0200, Marek Szyprowski wrote: > The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function > returns the number of the created entries in the DMA address space. > However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and > dma_unmap_sg must be called with the original number of the entries > passed to the dma_map_sg(). > > struct sg_table is a common structure used for describing a non-contiguous > memory buffer, used commonly in the DRM and graphics subsystems. It > consists of a scatterlist with memory pages and DMA addresses (sgl entry), > as well as the number of scatterlist entries: CPU pages (orig_nents entry) > and DMA mapped pages (nents entry). > > It turned out that it was a common mistake to misuse nents and orig_nents > entries, calling DMA-mapping functions with a wrong number of entries or > ignoring the number of mapped entries returned by the dma_map_sg() > function. > > To avoid such issues, lets use a common dma-mapping wrappers operating > directly on the struct sg_table objects and use scatterlist page > iterators where possible. This, almost always, hides references to the > nents and orig_nents entries, making the code robust, easier to follow > and copy/paste safe. Looks all sane. Acked-by: Gerd Hoffmann take care, Gerd