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=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 B11C3C433DB for ; Fri, 12 Mar 2021 18:11:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DC1AF64F48 for ; Fri, 12 Mar 2021 18:11:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DC1AF64F48 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2EC436B0070; Fri, 12 Mar 2021 13:11:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 29CCA6B0071; Fri, 12 Mar 2021 13:11:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 12CB86B0072; Fri, 12 Mar 2021 13:11:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0139.hostedemail.com [216.40.44.139]) by kanga.kvack.org (Postfix) with ESMTP id E62AD6B0070 for ; Fri, 12 Mar 2021 13:11:30 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 9C4441E0A for ; Fri, 12 Mar 2021 18:11:30 +0000 (UTC) X-FDA: 77912014740.17.4D8AE45 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf09.hostedemail.com (Postfix) with ESMTP id 612E76000108 for ; Fri, 12 Mar 2021 18:11:27 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D802DED1; Fri, 12 Mar 2021 10:11:28 -0800 (PST) Received: from [10.57.52.136] (unknown [10.57.52.136]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EB8E33F7D7; Fri, 12 Mar 2021 10:11:23 -0800 (PST) Subject: Re: [RFC PATCH v2 06/11] dma-direct: Support PCI P2PDMA pages in dma-direct map_sg To: Logan Gunthorpe , linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, linux-block@vger.kernel.org, linux-pci@vger.kernel.org, linux-mm@kvack.org, iommu@lists.linux-foundation.org Cc: Minturn Dave B , John Hubbard , Dave Hansen , Matthew Wilcox , =?UTF-8?Q?Christian_K=c3=b6nig?= , Jason Gunthorpe , Jason Ekstrand , Daniel Vetter , Dan Williams , Stephen Bates , Jakowski Andrzej , Christoph Hellwig , Xiong Jianxin References: <20210311233142.7900-1-logang@deltatee.com> <20210311233142.7900-7-logang@deltatee.com> <215e1472-5294-d20a-a43a-ff6dfe8cd66e@arm.com> From: Robin Murphy Message-ID: Date: Fri, 12 Mar 2021 18:11:17 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB X-Stat-Signature: wpm9cbcfdcfrbwq83usogidb3prq6pjz X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 612E76000108 Received-SPF: none (arm.com>: No applicable sender policy available) receiver=imf09; identity=mailfrom; envelope-from=""; helo=foss.arm.com; client-ip=217.140.110.172 X-HE-DKIM-Result: none/none X-HE-Tag: 1615572687-250177 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 2021-03-12 16:24, Logan Gunthorpe wrote: >=20 >=20 > On 2021-03-12 8:52 a.m., Robin Murphy wrote: >>> + >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sg->dma_addre= ss =3D dma_direct_map_page(dev, sg_page(sg), >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sg->offset, sg->length, dir, attrs); >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (sg->dma_a= ddress =3D=3D DMA_MAPPING_ERROR) >>> @@ -411,7 +440,7 @@ int dma_direct_map_sg(struct device *dev, struct >>> scatterlist *sgl, int nents, >>> =C2=A0 =C2=A0 out_unmap: >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 dma_direct_unmap_sg(dev, sgl, i, dir,= attrs | >>> DMA_ATTR_SKIP_CPU_SYNC); >>> -=C2=A0=C2=A0=C2=A0 return 0; >>> +=C2=A0=C2=A0=C2=A0 return ret; >>> =C2=A0 } >>> =C2=A0 =C2=A0 dma_addr_t dma_direct_map_resource(struct device *dev,= phys_addr_t >>> paddr, >>> diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c >>> index b6a633679933..adc1a83950be 100644 >>> --- a/kernel/dma/mapping.c >>> +++ b/kernel/dma/mapping.c >>> @@ -178,8 +178,15 @@ void dma_unmap_page_attrs(struct device *dev, >>> dma_addr_t addr, size_t size, >>> =C2=A0 EXPORT_SYMBOL(dma_unmap_page_attrs); >>> =C2=A0 =C2=A0 /* >>> - * dma_maps_sg_attrs returns 0 on error and > 0 on success. >>> - * It should never return a value < 0. >>> + * dma_maps_sg_attrs returns 0 on any resource error and > 0 on succ= ess. >>> + * >>> + * If 0 is returned, the mapping can be retried and will succeed onc= e >>> + * sufficient resources are available. >> >> That's not a guarantee we can uphold. Retrying forever in the vain hop= e >> that a device might evolve some extra address bits, or a bounce buffer >> might magically grow big enough for a gigantic mapping, isn't >> necessarily the best idea. >=20 > Perhaps this is just poorly worded. Returning 0 is the normal case and > nothing has changed there. The block layer, for example, will retry if > zero is returned as this only happens if it failed to allocate resource= s > for the mapping. The reason we have to return -1 is to tell the block > layer not to retry these requests as they will never succeed in the fut= ure. >=20 >>> + * >>> + * If there are P2PDMA pages in the scatterlist then this function m= ay >>> + * return -EREMOTEIO to indicate that the pages are not mappable by = the >>> + * device. In this case, an error should be returned for the IO as i= t >>> + * will never be successfully retried. >>> =C2=A0=C2=A0 */ >>> =C2=A0 int dma_map_sg_attrs(struct device *dev, struct scatterlist *= sg, int >>> nents, >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 enum dma_data= _direction dir, unsigned long attrs) >>> @@ -197,7 +204,7 @@ int dma_map_sg_attrs(struct device *dev, struct >>> scatterlist *sg, int nents, >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ents =3D dma_= direct_map_sg(dev, sg, nents, dir, attrs); >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 else >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ents =3D ops-= >map_sg(dev, sg, nents, dir, attrs); >>> -=C2=A0=C2=A0=C2=A0 BUG_ON(ents < 0); >>> + >> >> This scares me - I hesitate to imagine the amount of driver/subsystem >> code out there that will see nonzero and merrily set off iterating a >> negative number of segments, if we open the floodgates of allowing >> implementations to return error codes here. >=20 > Yes, but it will never happen on existing drivers/subsystems. The only > way it can return a negative number is if the driver passes in P2PDMA > pages which can't happen without changes in the driver. We are careful > about where P2PDMA pages can get into so we don't have to worry about > all the existing driver code out there. Sure, that's how things stand immediately after this patch. But then=20 someone comes along with the perfectly reasonable argument for returning=20 more expressive error information for regular mapping failures as well=20 (because sometimes those can be terminal too, as above), we start to get=20 divergent behaviour across architectures and random bits of old code=20 subtly breaking down the line. *That* is what makes me wary of making a=20 fundamental change to a long-standing "nonzero means success" interface..= . Robin.