From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:400e:c00::22e; helo=mail-pf0-x22e.google.com; envelope-from=heyi.guo@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 537B7222630DA for ; Fri, 23 Feb 2018 22:17:18 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id j24so4415451pff.12 for ; Fri, 23 Feb 2018 22:23:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:date:to:cc:subject:message-id:mime-version:content-disposition :user-agent; bh=yIAgEVRAQqyjoJZtChn2DQL8dp/gytUm19ReONSp5Wk=; b=TWaLjuvuf5Cpoi6joAixAzvSWVruof4asGsBlzMQMJ9bW95DsbRvg0MPIoA15N7EoS JOFhkonUXYTSaeHY4y8uq5bigPQzDveHpWkvZIE6HmxsIY9LsBDwqo93Kbj730H65l6a l3DfQM3QTgcIiFtR1AhrCW5JJmQCywRDYaHic= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:mime-version :content-disposition:user-agent; bh=yIAgEVRAQqyjoJZtChn2DQL8dp/gytUm19ReONSp5Wk=; b=lILf4eg6ZFaoHS9Dx+YlfNccugpW+SkfBhfexIn9IxjnxmRIHdlU9iRDuNqyOYQXMq 5ENpJvJbTOijvCQRN+0xQ0SnXjiFcA3TDsiw6P3jgRDMpx2K52dDOr8HKCI/kCkHFO1k /h8VhscFoe8WOhblCeFIISE84YDlmJWmp1gAS9pi59BnGmbR/QpVdwphisZGw+rZzRa1 sOXtZS6l7cIqflwn0pwHPXtKOP3K3Dr/D1RZvRe6eqJnBzKpvsenVWjr2DpBnMjCUbzy Ulh+ZQxByVktRf0UaFidJKz9H1U2BOJOMoFuMU68rDs7KzmJnLAMWEI02GZAW2wNM7ef oPHw== X-Gm-Message-State: APf1xPB2Nyef/mJNxe6AjwcGdJtQ5TYjFDWhteyUycExHKqi4D8Y2Ik0 SBHZISCNVbfy1QfrWUopVptdIN00h80= X-Google-Smtp-Source: AH8x225/4EqFWPzApJoDyezTKrLZXj9wTM6j9PfXypxf1f8RTGBpGu6ViNL2O45NmAydPk0ItTN0Tw== X-Received: by 10.98.214.10 with SMTP id r10mr4117895pfg.8.1519453400798; Fri, 23 Feb 2018 22:23:20 -0800 (PST) Received: from SZX1000114654 ([104.237.91.49]) by smtp.gmail.com with ESMTPSA id a138sm8198590pfd.47.2018.02.23.22.23.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Feb 2018 22:23:20 -0800 (PST) From: Guo Heyi X-Google-Original-From: Guo Heyi Date: Sat, 24 Feb 2018 14:23:16 +0800 To: edk2-devel@lists.01.org Cc: Star Zeng , Eric Dong , Ruiyu Ni Message-ID: <20180224062316.GA111715@SZX1000114654> MIME-Version: 1.0 User-Agent: Mutt/1.5.24 (2015-08-30) Subject: MdeModulePkg/UefiBootManagerLib: recursive call of BmRepairAllControllers X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Feb 2018 06:17:19 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi folks, In BmDriverHealth.c, function BmRepairAllControllers may recursively call itself if some driver health protocol returns EfiDriverHealthStatusReconnectRequired. However, if there is something wrong in some 3rd party driver (e.g. PCI oprom), the driver health protocol of that driver may always return such status even after one and another reconnect. The endless iteration will cause stack overflow and then system exception, and it may be not easy to find that the exception is actually caused by stack overflow. So does it make sense to set a maximum count of this recursive call to avoid whole system hang even there is a buggy 3rd party driver? Thanks, Gary (Heyi Guo)