[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 05/10] xen/x86: Use ASSERT instead of VIRTUAL_BUG_ON for phys_to_nid


  • To: Wei Chen <wei.chen@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 26 Apr 2022 11:02:42 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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=x35vDbHqDus8D94MvlrwML05cIVW0G4PvZ4nKACIxOU=; b=JboabU6dHi8CWB/w/wP692hSbgJYp+dsjXoqPPTMCpTje9xhTzbkrrUWUgt2Yo3IBHdtmgT22TCKKDdJWUJ7ctetKqrzSwgTgyNkTZbKXudJZrSSb2hvVBLgTz6o4Hz8rCGt928xgzR/T0aLH9U7M3SJi4gLZNwKroPJGSH+z1Ohiqx04B+uuDYCSKtsFXcgE/DXWuSVI1nW9w85PPfuOnbDxscdUP+d3pcQp4aHaoN0H7yJktKszbFJ3F0jlyiCPMhG1M/vdT9LWTUZV6mW7PXy5oy106Wm0ilmSbm8M5iSAhb5iJp1zstNv26r0KSmJy/QzdzxtiMBUo+zuvjHwg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YRtS06mtuDq0oylCJVG5/ZUTiMyV1TWrj2kApCtBGLLmAjVeABTYxzU+X+nqOJ24wcsMsh/dYg/XsZ8TGgsdEejm0B6JaPqHc/yi1ErmFAc4uviULa+BlDJFrk8GZS9R8vCEAGrkxdqIISJkfflY+vtGBnv1t21k0z6sJ8sVCy6fz0mxCt0EEfXxWMr8ZiiVI4uIZtJjDODzUdRcCB6O+ABZNS3DrzAFvloQ+IaPRCbDi0/w62L/9nI3S+zJm1iXOg5TGmXlOfZYvjmFEPhVfyWzExKdOGPtUZToOqtJp1b6edboBZNX7ALyG6D+4PeHigdpI7UdMtzsccJ7vXm2yQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: nd@xxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 26 Apr 2022 09:02:59 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 18.04.2022 11:07, Wei Chen wrote:
> VIRTUAL_BUG_ON is an empty macro used in phys_to_nid. This
> results in two lines of error-checking code in phys_to_nid
> that is not actually working and causing two compilation
> errors:
> 1. error: "MAX_NUMNODES" undeclared (first use in this function).
>    This is because in the common header file, "MAX_NUMNODES" is
>    defined after the common header file includes the ARCH header
>    file, where phys_to_nid has attempted to use "MAX_NUMNODES".
>    This error was resolved when we moved the definition of
>    "MAX_NUMNODES" to x86 ARCH header file. And we reserve the
>    "MAX_NUMNODES" definition in common header file through a
>    conditional compilation for some architectures that don't
>    need to define "MAX_NUMNODES" in their ARCH header files.

No, that's setting up a trap for someone else to fall into, especially
with the #ifdef around the original definition. Afaict all you need to
do is to move that #define ahead of the #include in xen/numa.h. Unlike
functions, #define-s can reference not-yet-defined identifiers.

> 2. error: wrong type argument to unary exclamation mark.
>    This is because, the error-checking code contains !node_data[nid].
>    But node_data is a data structure variable, it's not a pointer.
> 
> So, in this patch, we use ASSERT instead of VIRTUAL_BUG_ON to
> enable the two lines of error-checking code. And fix the left
> compilation errors by replacing !node_data[nid] to
> !node_data[nid].node_spanned_pages.
> 
> Because when node_spanned_pages is 0, this node has no memory,
> numa_scan_node will print warning message for such kind of nodes:
> "Firmware Bug or mis-configured hardware?".

This warning is bogus - nodes can have only processors. Therefore I'd
like to ask that you don't use it for justification. And indeed you
don't need to: phys_to_nid() is about translating an address. The
input address can't be valid if it maps to a node with no memory.

Jan




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.