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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id EE9A6C433F5 for ; Thu, 14 Apr 2022 10:33:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=IYYtHJ2Fsh95+6/AzsrlFf7aZmR0Cy75zyzrP/7wLs4=; b=EZ6p4fdGaIvwgu rNuuZcgZfww9waMhca+/5xa8sMNP4HA4WxOtulDd0o+tGaxObAGQ8OQ16MIWwqSg3vk1uuOkbWsvJ cyEZafwpQ8Rh+JOegkaYkl7WgudV0YrUFRnsyFsKTOFowszV4xR9V2okFBdxfcp9L7JcHx9DeYkRA XHgT4BLg9JZJtPcQiCbygsu7pQ+WQk2vTeRFS1rfvankHQBcrKfzzQSl1F5GdzqWW6+x9pSqtgWfY bvrHTWvm8BFCdIkml1Cgri/VZeDRo1H49qX0l3fBjEsaPEuLYcADcX4WiynW8iEfxBGweNl0NNG/N BBe7imAszvY3ufl3hsBQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1newmR-0058Wq-OI; Thu, 14 Apr 2022 10:32:51 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1newmO-0058V1-LF for linux-arm-kernel@lists.infradead.org; Thu, 14 Apr 2022 10:32:50 +0000 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 5C563139F; Thu, 14 Apr 2022 03:32:45 -0700 (PDT) Received: from [10.57.41.19] (unknown [10.57.41.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8DE0B3F5A1; Thu, 14 Apr 2022 03:32:43 -0700 (PDT) Message-ID: <13c91dfb-c540-ed8d-daa7-eab7207df221@arm.com> Date: Thu, 14 Apr 2022 11:32:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [PATCH] iommu/arm-smmu-v3: Align size in __arm_smmu_tlb_inv_range Content-Language: en-GB To: Nicolin Chen Cc: will@kernel.org, joro@8bytes.org, thunder.leizhen@huawei.com, jgg@ziepe.ca, tglx@linutronix.de, john.garry@huawei.com, jean-philippe@linaro.org, christophe.jaillet@wanadoo.fr, linux-arm-kernel@lists.infradead.org, iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org References: <20220413041745.35174-1-nicolinc@nvidia.com> <37c02fc4-d793-b003-f612-206c987a8a42@arm.com> From: Robin Murphy In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220414_033248_790309_4E696CF8 X-CRM114-Status: GOOD ( 20.63 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2022-04-13 21:19, Nicolin Chen wrote: > Hi Robin, > > On Wed, Apr 13, 2022 at 02:40:31PM +0100, Robin Murphy wrote: >> On 2022-04-13 05:17, Nicolin Chen wrote: >>> To calculate num_pages, the size should be aligned with >>> "page size", determined by the tg value. Otherwise, its >>> following "while (iova < end)" might become an infinite >>> loop if unaligned size is slightly greater than 1 << tg. >> >> Hmm, how does a non-page-aligned invalidation request get generated in >> the first place? > > I don't have the testing environment because it was a bug, > reported by a client who uses SVA feature on top of SMMU. > > But judging from the log, the non-page-aligned inv request > was coming from an likely incorrect end address, e.g. > { start = 0xff10000, end = 0xff20000 } > So the size turned out to be 0x10001, unaligned. > > I don't have a full call trace on hand right now to see if > upper callers are doing something wrong when calculate the > end address, though I've asked the owner to check. > > By looking at the call trace within arm_smmu_* functions: > __arm_smmu_tlb_inv_range > arm_smmu_tlb_inv_range_asid > arm_smmu_mm_invalidate_range > {from mm_notifier_* functions} > > There's no address alignment check. Although I do think we > should fix the source who passes down the non-page-aligned > parameter, the SMMU driver shouldn't silently dead loop if > a set of unaligned inputs are given, IMHO. Oh, sure, I'm not saying we definitely don't need to fix anything, I'd just like to get a better understanding of *what* we're fixing. I'd have (naively) expected the mm layer to give us page-aligned quantities even in the SVA notifier case, so if we've got a clear off-by-one somewhere in that path we should fix that before just blindly over-invalidating to paper over it; if we still also want to be robust at the SMMU driver end just in case, something like "if (WARN_ON(num_pages == 0)) num_pages = 1;" might be more appropriate. However if it turns out that we *can* actually end up with unsanitised input from some userspace unmap interface getting this far, then a silent fixup is the best option, but if so I'd still like to confirm that we're rounding in the same direction as whoever touched the pagetables (since it can't have been us). Thanks, Robin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel