[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <X8YWa8IUCgOARYMS@kroah.com>
Date: Tue, 1 Dec 2020 11:09:47 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: shuo.a.liu@...el.com
Cc: linux-kernel@...r.kernel.org, x86@...nel.org,
"H . Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Sean Christopherson <sean.j.christopherson@...el.com>,
Yu Wang <yu1.wang@...el.com>,
Reinette Chatre <reinette.chatre@...el.com>,
Zhi Wang <zhi.a.wang@...el.com>,
Zhenyu Wang <zhenyuw@...ux.intel.com>
Subject: Re: [PATCH v6 06/18] virt: acrn: Introduce VM management interfaces
On Tue, Dec 01, 2020 at 05:38:41PM +0800, shuo.a.liu@...el.com wrote:
> + vm_param->reserved0 = 0;
> + vm_param->reserved1 = 0;
NO!
This means that userspace can put whatever crud they want in those
fields, and you will happily zero it out. Then, when those reserved
fields are wanted to be used in the future, you will take those values
from userspace and accept them as a valid value. But, since userspace
was sending crud before, now you will take that crud and do something
with it.
TEST IT to verify that it is zero, that way userspace gets it right the
first time, and you don't get it wrong later, as you can not change it
later.
thaqnks,
greg k-h
Powered by blists - more mailing lists