[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [PATCH] x86/altp2m: help gcc13 to avoid it emitting a warning
- To: "Beulich, Jan" <JBeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
- Date: Tue, 14 Mar 2023 01:55:18 +0000
- Accept-language: en-US
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vI3F0rj7QWzkvpHVeussW4i2MPFpmN3sNkoxZOK3/Q8=; b=emATcI8E06UWEi91va9Tt4onVPbGDqmHWHfcqh27WMn6v8C+LU78JPEzWaqmpE3IV3XNGBaqh36zY6/Fd1QyaPwREDe640Sg14NYqYdeE+ZMsIFd4qSxD7zVBrzJLCBtJgCdLhVVRLMP19+9zkDmU6AE69BaHMF9UI/8UNJWD9bdFwP2BOX2Y7upHZ7Ne2a5EACn8cPMC/QJu1lc8GvwPpZ+un7iiKjC9eUMpKN4uKu39wr2Ll8Z4bh8p5TbzLGn8P4LLpdA1JHqVypiBIQvFn0XliBtLm+0/gXOxyQeT2i8RNqtSCvu9iJw92F7E+WF1hDOr1lNGIxBwX0GQl2bQw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T6O/vnIaxbZhbcPwHr1jjUSIlqVwsNb7wTAmXhV56MDfUmh9LNsOnAN4njKQAPyl6WjEFquLDaRkjynQIy9isKRbfkX/W6cQ9WGKPtTw1/N417/9Oezy2l02ufhLjwsSi9XLrfgSaEn69nMRXUGDwYhxnLLYWQaFQiQPBQvOsqTTOacRkjzhsG3dOkbLKX+VjKtYUN3WmdTjLBJYsI2MOU0cCHOUbZrN54WUuRX6WJ0sg0jmd6l6bVoa+EFSkXJNO/uwp1STEzvgrMAFusCc+i4Yt+LPw7gfhmwCPetmXX5eNbnz4mwop+dOlJbcZr3E4UEjDrpsOWC5liWW1VMb+Q==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com;
- Cc: "andrew.cooper3@xxxxxxxxxx" <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Pau Monné, Roger <roger.pau@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
- Delivery-date: Tue, 14 Mar 2023 01:55:32 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHZTaI8c6Gg7osE6EW0fUR5A226Ra75lKrg
- Thread-topic: [PATCH] x86/altp2m: help gcc13 to avoid it emitting a warning
> From: Jan Beulich <jbeulich@xxxxxxxx>
> Sent: Friday, March 3, 2023 3:32 PM
>
> Switches of altp2m-s always expect a valid altp2m to be in place (and
> indeed altp2m_vcpu_initialise() sets the active one to be at index 0).
> The compiler, however, cannot know that, and hence it cannot eliminate
> p2m_get_altp2m()'s case of returnin (literal) NULL. If then the compiler
> decides to special case that code path in the caller, the dereference in
> instances of
>
> atomic_dec(&p2m_get_altp2m(v)->active_vcpus);
>
> can, to the code generator, appear to be NULL dereferences, leading to
>
> In function 'atomic_dec',
> inlined from '...' at ...:
> ./arch/x86/include/asm/atomic.h:182:5: error: array subscript 0 is outside
> array bounds of 'int[0]' [-Werror=array-bounds=]
>
> Aid the compiler by adding a BUG_ON() checking the return value of the
> problematic p2m_get_altp2m(). Since with the use of the local variable
> the 2nd p2m_get_altp2m() each will look questionable at the first glance
> (Why is the local variable not used here?), open-code the only relevant
> piece of p2m_get_altp2m() there.
>
> To avoid repeatedly doing these transformations, and also to limit how
> "bad" the open-coding really is, convert the entire operation to an
> inline helper, used by all three instances (and accepting the redundant
> BUG_ON(idx >= MAX_ALTP2M) in two of the three cases).
>
> Reported-by: Charles Arnold <carnold@xxxxxxxx>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>
Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
|
