From nobody Tue May 7 16:55:00 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org ARC-Seal: i=1; a=rsa-sha256; t=1612288102; cv=none; d=zohomail.com; s=zohoarc; b=UI2wSXno4ufvgg96CL/bqy9Vsm2d2cFrVEwEiU0SEclIqP14vm5+GvBQCFM3WdPe9Y2xCXqZLJQJ1kwvgRZkIp4JV4I+Ji/VI/6TXGJw6i+IJD6DMyxdzFA0+Sk2JnJ7GufS28mHwtO2F0SjzSvdd8ed/7MKun7tIBRrykkiJPw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1612288102; h=Content-Type:Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To; bh=DKlz0azmRzRqalavXAJ75SJ2E8R/u6GvGWeorFhhtGo=; b=UMh6zkUKDlV4zLIwDBEDGKkJFJb8bCmIiB5SjdwYQ6d3b7vNKyjgzKY4ckwi+4TPtI5W/xScv0jL4v9W6NCMqQdjgd0xbWU+fuRM66Su5FrXykcjo+pTdFlcPwHtkXqrNi5LKqlleqkca5jNIK9yuCbfayXgqGYhxjo4K/NaU9E= ARC-Authentication-Results: i=1; mx.zohomail.com; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1612288102355633.9500930664426; Tue, 2 Feb 2021 09:48:22 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.80675.147715 (Exim 4.92) (envelope-from ) id 1l6zmY-0000vn-5G; Tue, 02 Feb 2021 17:48:06 +0000 Received: by outflank-mailman (output) from mailman id 80675.147715; Tue, 02 Feb 2021 17:48:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1l6zmY-0000vg-1Q; Tue, 02 Feb 2021 17:48:06 +0000 Received: by outflank-mailman (input) for mailman id 80675; Tue, 02 Feb 2021 17:48:04 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1l6zmW-0000vb-Fy for xen-devel@lists.xenproject.org; Tue, 02 Feb 2021 17:48:04 +0000 Received: from mailhost.m5p.com (unknown [74.104.188.4]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c5c730fc-f88f-4553-aaf0-ffa11e86cc42; Tue, 02 Feb 2021 17:48:01 +0000 (UTC) Received: from m5p.com (mailhost.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:f7]) by mailhost.m5p.com (8.15.2/8.15.2) with ESMTPS id 112HllcC022963 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 2 Feb 2021 12:47:53 -0500 (EST) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.15.2/8.15.2/Submit) id 112HllHT022962; Tue, 2 Feb 2021 09:47:47 -0800 (PST) (envelope-from ehem) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c5c730fc-f88f-4553-aaf0-ffa11e86cc42 Date: Tue, 2 Feb 2021 09:47:47 -0800 From: Elliott Mitchell To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Volodymyr Babchuk Subject: [PATCH] xen/arm: domain_build: Ignore device nodes with invalid addresses Message-ID: MIME-Version: 1.0 Content-Disposition: inline X-Spam-Status: No, score=0.4 required=10.0 tests=KHOP_HELO_FCRDNS autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mattapan.m5p.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The handle_device() function has been returning failure upon encountering a device address which was invalid. A device tree which had such an entry has now been seen in the wild. As it causes no failures to simply ignore the entries, ignore them. Signed-off-by: Elliott Mitchell --- I'm starting to suspect there are an awful lot of places in the various domain_build.c files which should simply ignore errors. This is now the second place I've encountered in 2 months where ignoring errors was the correct action. I know failing in case of error is an engineer's favorite approach, but there seem an awful lot of harmless failures causing panics. This started as the thread "[RFC PATCH] xen/arm: domain_build: Ignore empty memory bank". Now it seems clear the correct approach is to simply ignore these entries. This seems a good candidate for backport to 4.14 and certainly should be in 4.15. --- xen/arch/arm/domain_build.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 374bf655ee..c0568b7579 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -1407,9 +1407,9 @@ static int __init handle_device(struct domain *d, str= uct dt_device_node *dev, res =3D dt_device_get_address(dev, i, &addr, &size); if ( res ) { - printk(XENLOG_ERR "Unable to retrieve address %u for %s\n", - i, dt_node_full_name(dev)); - return res; + printk(XENLOG_ERR "Unable to retrieve address of %s, index %u\= n", + dt_node_full_name(dev), i); + continue; } =20 res =3D map_range_to_domain(dev, addr, size, &mr_data); --=20 2.20.1 --=20 (\___(\___(\______ --=3D> 8-) EHM <=3D-- ______/)___/)___= /) \BS ( | ehem+sigmsg@m5p.com PGP 87145445 | ) / \_CS\ | _____ -O #include O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445