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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C06BAC4332F for ; Wed, 12 Oct 2022 18:34:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229695AbiJLSeJ (ORCPT ); Wed, 12 Oct 2022 14:34:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50744 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229459AbiJLSeH (ORCPT ); Wed, 12 Oct 2022 14:34:07 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 06677923E0 for ; Wed, 12 Oct 2022 11:34:07 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 96EBE615A0 for ; Wed, 12 Oct 2022 18:34:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EAEECC433D6; Wed, 12 Oct 2022 18:34:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1665599646; bh=8Duuv1CJiReutaKggzEjLN1RfuY6IKEsm6vG6iA4b6Q=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=gb0tGoab1e5U33ksqqiu2JqGlCq34SqFpmwtzhtYs2atdLxrWTan469wbsVUsEazb Ink9/hJ9lKJBDmgPcLVtBueTe6AwtBnWCmtIZp1o3pKKEbskq/HnwmfMZMqmTTS+3I h05O5ezGTMRXBlu4IKx5KJW5fXf9ZmY7zXipQ1NurOvzczjfI36VoeSDqJv/tJ+QDH 5lHRce6TYPHX9YJRmxoOs+zIXmBMsgoXDsalKRbg2EhNWzQ+/hl2gjKyfLTncfFLJc hMdoELcce1eSqALSxwguTFkLJiT/DzxmIwcAHkZQDDwI9BRC9ezwfRA4CgeQw8Zloe wbOLULWP9xbFQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1oigYN-00G8SS-DX; Wed, 12 Oct 2022 19:34:03 +0100 Date: Wed, 12 Oct 2022 19:33:12 +0100 Message-ID: <87o7ughoyf.wl-maz@kernel.org> From: Marc Zyngier To: Eric Ren Cc: kvm@vger.kernel.org, kvmarm , kvmarm@lists.cs.columbia.edu, Eric Auger , Suzuki K Poulose , James Morse , Alexandru Elisei , Oliver Upton Subject: Re: [PATCH] KVM: arm64: vgic: fix wrong loop condition in scan_its_table() In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: renzhengeek@gmail.com, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, kvmarm@lists.cs.columbia.edu, eauger@redhat.com, suzuki.poulose@arm.com, james.morse@arm.com, Alexandru.Elisei@arm.com, oliver.upton@linux.dev X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org Hi Eric, Before I comment on this patch, a couple of things that need addressing: > "Cc: marc.zyngier@arm.com, cdall@linaro.org" None of these two addresses are valid anymore, and haven't been for several years. Please consult the MAINTAINERS file for up-to-date addresses for current maintainers and reviewers, all of whom should be Cc'd on this email. I've now added them as well as Eric Auger who has written most of the ITS migration code, and the new mailing list (the Columbia list is about to be killed). On Wed, 12 Oct 2022 17:59:25 +0100, Eric Ren wrote: > > Reproducer hints: > 1. Create ARM virt VM with pxb-pcie bus which adds > extra host bridges, with qemu command like: > > ``` > -device pxb-pcie,bus_nr=8,id=pci.x,numa_node=0,bus=pcie.0 \ > -device pcie-root-port,..,bus=pci.x \ > ... > -device pxb-pcie,bus_nr=37,id=pci.y,numa_node=1,bus=pcie.0 \ > -device pcie-root-port,..,bus=pci.y \ > ... > > ``` > 2. Perform VM migration which calls save/restore device tables. > > In that setup, we get a big "offset" between 2 device_ids ( > one is small, another is big), which makes unsigned "len" round > up a big positive number, causing loop to continue exceptionally. You'll have to spell it out for me here. If you have a very sparse device ID and you are only using a single level device table, you are bound to have a large len. Now, is the issue that 'size' is so large that it is negative as an 'int'? Describing the exact situation you're in would help a lot. > > Signed-off-by: Eric Ren > --- > arch/arm64/kvm/vgic/vgic-its.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c > index 24d7778d1ce6..673554ef02f9 100644 > --- a/arch/arm64/kvm/vgic/vgic-its.c > +++ b/arch/arm64/kvm/vgic/vgic-its.c > @@ -2141,7 +2141,7 @@ static int scan_its_table(struct vgic_its *its, gpa_t base, int size, u32 esz, > int start_id, entry_fn_t fn, void *opaque) > { > struct kvm *kvm = its->dev->kvm; > - unsigned long len = size; > + ssize_t len = size; This feels wrong, really. If anything, all these types should be unsigned, not signed. Signed types in this context make very little sense... Thanks, M. -- Without deviation from the norm, progress is not possible.