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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3B041C3DA6F for ; Thu, 24 Aug 2023 16:39:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 43178280075; Thu, 24 Aug 2023 12:39:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3E1AB8E0011; Thu, 24 Aug 2023 12:39:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2CFAE280075; Thu, 24 Aug 2023 12:39:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 1BB248E0011 for ; Thu, 24 Aug 2023 12:39:47 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id DDC4DB1F8B for ; Thu, 24 Aug 2023 16:39:46 +0000 (UTC) X-FDA: 81159559572.23.F05175A Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf24.hostedemail.com (Postfix) with ESMTP id C0230180027 for ; Thu, 24 Aug 2023 16:39:44 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=none; spf=pass (imf24.hostedemail.com: domain of robin.murphy@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=robin.murphy@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692895185; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Gi4DHHpiuDC2ExivpLxRxLrKuDDG5skrqJppwxenWHk=; b=5/mX8RfafkGpB2IrGK+L4vJpPGVCEb1fhpcrvD2TSEMpQTRXuokVN+lCiPwHylcAenkejw hGaB+QIy1K5BeW182jvce2b6MPY4w26nnloL0SQ8+KYnjDDjOHFv74ZsfsUBkWPjMWMpca D9aaZrGvFmXXKDa6yQ3AEg21ZLw0Zjo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692895185; a=rsa-sha256; cv=none; b=rh0HXj28Sp2vSYi9kboRLbfOZRrvuGPiCnjOqVrdjFZVcrLJewp9KBFLb53iU4aBxIORMQ fRwY/HFUbaRqAYj5wNgxt/tJ+8hWJZzW0zgis74s8zDvTcai6qO0ajr0AONXpKMVg79VaP 9LX2qLE27J9SuCmajt/WsFLKj40u91Y= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none; spf=pass (imf24.hostedemail.com: domain of robin.murphy@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=robin.murphy@arm.com; dmarc=pass (policy=none) header.from=arm.com 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 E5354D75; Thu, 24 Aug 2023 09:40:23 -0700 (PDT) Received: from [10.1.196.40] (e121345-lin.cambridge.arm.com [10.1.196.40]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C53F23F762; Thu, 24 Aug 2023 09:39:42 -0700 (PDT) Message-ID: <46702101-01b3-1d1d-e5c0-f869c5b88ea5@arm.com> Date: Thu, 24 Aug 2023 17:39:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH] Fix folio conversion in __dma_page_dev_to_cpu() Content-Language: en-GB To: "Matthew Wilcox (Oracle)" , Russell King , Andrew Morton Cc: Marek Szyprowski , linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org References: <20230823191852.1556561-1-willy@infradead.org> From: Robin Murphy In-Reply-To: <20230823191852.1556561-1-willy@infradead.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: C0230180027 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: fqeg98mxqtt7ch4666bpc37rifjo3u5w X-HE-Tag: 1692895184-900970 X-HE-Meta: U2FsdGVkX19NF5qTaXpw1gfdmCeEpUpZd7k2F9Kp1bfGyjootsG4b2sXpus9xDsvZDuDJpapwcr53Luhcab6PQuYO+vhVOqeF7k1PrEVWaZ9Wqz40GhmjNlfXOHtenmhXobSvHn+OFmVhv321EAbM52uGmLfSFPeHf2yY/AA/4R31fs2OkwWwILL1lTSdEiLJHkQfl6Jfs3nqo4ZJ7mpl9+GPZSirJxSIwSe4iu6vI8dqGo38LTfqmqt42lD+TO+Fvy2q2JxOAATpVWhBK043lJQOzqpugfrHur7cx2RSKWD/ycCSMHENh/EBZjJeicPG8hd5+saeWZS/2gCg6qGzwo1ql6bQSsLRMfVZQw7XBqgI5N5kyWzO+se+DmV/LnGE7a8ZaVw6OCsQR25DD2aTJi5glQeNBDo19JsciKWkB2A/RFxLsE98ww1OcmnM10UYXO57O5yQxFlfH+6GVwCJEc9SOHtAyNj7NyjSUBRxdbcxPxDYfI7nNKO/xC5hyMWL05Z27tipcLQsq+6f+n1H5SMbnvnsaENY9Mq/bjpUM3t5GCtWK0U5P2zmpIlxRvLtnpNV4lehNUvzcUBVvvddx0MHQkAwHrS/BQcgFyS5/FHDjDvzNqrDyHxXLyiWWgmIJqtIoSsMSoACjIY+QbHTAOBS/+VsMWxn5J5I3YlmsMC8UmSZuNUx1M5m8cxBmTArp4x2laz2JEF5Ll++v0r49Ny4LBIfvpKAXXCmzW2Su8d+zlDxLy64FxziwNSptdV6x6WPLu4Dlrotr+Nj4sSCkG+PuuF9NGUWgOU743hMsjl8m1Nnd6NK106v3Bb1dFOMQA9cnkduRFjGkLKpmZFHS7hY3SaYOXGfuLzPtMoazgGyJvoZ4H5HCgFpa7JURXNVJE3xjuWgOo1YUtbww57HLPgXMKgm0XSBCHkeiqNqeRemgfQ6djR345E3blIC0AWlGUgAZrkMpFcrdMKLSu 60wbGr2H 4JFBUFi4IJJshG1faBq7maSQ2QssTH37UGOtOjmTOwicA8T/+AKYSHE4L0ZXTy2mEzRv2VrESpvVyXBLuid+o45k1WxG1NZfyAzR0AJ3ujolhh+bAVLvYYlL11ue9el2/jFWU4bLtth8B/tZu1aKE6jXhRR2MuRNYayzVkXN/cd2mppip2z9ln21kF2v6cPKpDFTTW3mnDyKYlpGdExybnO7dkns7c/PBzH0rlge5HUrZ+kahgmjKYOzOX7A1edUiT7aTNq1KhreLYzNXqatx4MgcOK5KTCYBMXbW8kWzYrqVpW2xe2N89eSEZ1U1kUbmp95u327O/GouO6E= 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 23/08/2023 8:18 pm, Matthew Wilcox (Oracle) wrote: > Russell and Marek pointed out some assumptions I was making about how sg > lists work; eg that they are limited to 2GB and that the initial offset > lies within the first page (or at least within the first folio that a > page belongs to). While I think those assumptions are true, it's not > too hard to write a version which does not have those assumptions and > also calculates folio_size() only once per loop iteration. FWIW, sg->offset > PAGE_SIZE has certainly been known to happen for quasi-legitimate reasons. Last time it came up[1], I think the conclusion in that case was that the crypto scatterwalk code wasn't unreasonably wrong, though could perhaps do better, but it was also straightforward enough to be robust against it within the DMA API so we should just do that anyway (commit 29a90b708938). As for >2GB segments, we've certainly seen cases of users mapping absurdly large buffers and overflowing dma_length[2], so I would imagine it's only the improbability of allocating that much physically-contiguous memory which keeps individual segment lengths from getting up to UINT_MAX ;) Cheers, Robin. [1] https://lore.kernel.org/linux-iommu/be3bb850-a9f2-61fa-e378-eb44489256e0@chelsio.com/ [2] https://lore.kernel.org/linux-iommu/fbdbb8c0e550ae559ea3eedc1fea084c0111f202.1564418681.git.robin.murphy@arm.com/ > --- > arch/arm/mm/dma-mapping.c | 20 ++++++++++---------- > 1 file changed, 10 insertions(+), 10 deletions(-) > > diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c > index 0474840224d9..5409225b4abc 100644 > --- a/arch/arm/mm/dma-mapping.c > +++ b/arch/arm/mm/dma-mapping.c > @@ -695,7 +695,6 @@ static void __dma_page_cpu_to_dev(struct page *page, unsigned long off, > static void __dma_page_dev_to_cpu(struct page *page, unsigned long off, > size_t size, enum dma_data_direction dir) > { > - struct folio *folio = page_folio(page); > phys_addr_t paddr = page_to_phys(page) + off; > > /* FIXME: non-speculating: not required */ > @@ -710,18 +709,19 @@ static void __dma_page_dev_to_cpu(struct page *page, unsigned long off, > * Mark the D-cache clean for these pages to avoid extra flushing. > */ > if (dir != DMA_TO_DEVICE && size >= PAGE_SIZE) { > - ssize_t left = size; > + struct folio *folio = pfn_folio(paddr / PAGE_SIZE); > size_t offset = offset_in_folio(folio, paddr); > > - if (offset) { > - left -= folio_size(folio) - offset; > - folio = folio_next(folio); > - } > + for (;;) { > + size_t sz = folio_size(folio) - offset; > > - while (left >= (ssize_t)folio_size(folio)) { > - left -= folio_size(folio); > - set_bit(PG_dcache_clean, &folio->flags); > - if (!left) > + if (size < sz) > + break; > + if (!offset) > + set_bit(PG_dcache_clean, &folio->flags); > + offset = 0; > + size -= sz; > + if (!size) > break; > folio = folio_next(folio); > }