From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from blyat.fensystems.co.uk (blyat.fensystems.co.uk [54.246.183.96])
 by mx.groups.io with SMTP id smtpd.web11.10464.1633951721808097403
 for <devel@edk2.groups.io>;
 Mon, 11 Oct 2021 04:28:43 -0700
Authentication-Results: mx.groups.io;
 dkim=missing; spf=pass (domain: ipxe.org, ip: 54.246.183.96, mailfrom: mcb30@ipxe.org)
Received: from pudding.home (unknown [188.94.42.109])
	by blyat.fensystems.co.uk (Postfix) with ESMTPSA id D8920440F9;
	Mon, 11 Oct 2021 11:28:28 +0000 (UTC)
Subject: Re: [edk2-devel] [PATCH] MdeModulePkg/Core/Dxe: Acquire a lock when iterating gHandleList
To: devel@edk2.groups.io, hua.ma@intel.com
Cc: Jian J Wang <jian.j.wang@intel.com>, Liming Gao
 <gaoliming@byosoft.com.cn>, Dandan Bi <dandan.bi@intel.com>,
 Ray Ni <ray.ni@intel.com>
References: <7c0683f0a02729d8c75dcb631fec2941c834629e.1633948972.git.hua.ma@intel.com>
From: "Michael Brown" <mcb30@ipxe.org>
Message-ID: <f7575ba1-c108-e5da-db3d-7229af52526a@ipxe.org>
Date: Mon, 11 Oct 2021 12:28:21 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <7c0683f0a02729d8c75dcb631fec2941c834629e.1633948972.git.hua.ma@intel.com>
X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00
	autolearn=ham autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
	blyat.fensystems.co.uk
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit

On 11/10/2021 11:45, Ma, Hua wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3680
> 
> This patch fixes the following issue:
> 
> The global variable gHandleList is a linked list.
> This list is locked when a entry is added or removed from the list,
> but there is no lock when iterating this list in function
> CoreValidateHandle().
> It can lead to "Handle.c (76): CR has Bad Signature" assertion if the
> iterated entry in the list is just removed by other task during iterating.
> Locking the list when iterating can fix this issue.

At a first glance, it looks as though if the caller does not already 
hold the lock, then the result from CoreValidateHandle() may be invalid 
by the time that control returns to the caller.

Under what circumstances is it valid to call CoreValidateHandle() when 
the caller does not _already_ hold the lock (i.e. IsLocked==FALSE)?

Thanks,

Michael