Re: [Xen-devel] [PATCH] use consistent values when consuming runtime-changeable parameters
On 10/30/2018 02:44 PM, Jan Beulich wrote: > There's no guarantee that e.g. a switch() control expression's memory > operand(s) get(s) read just once. Guard against the compiler producing > "unexpected" code by sprinkling around some ACCESS_ONCE(). > > I'm leaving alone opt_conswitch[]: It gets accessed in quite a few > places anyway, and an intermediate change won't have any severe effect > afaict. > > Signed-off-by: Jan Beulich Acked-by: George Dunlap ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] use consistent values when consuming runtime-changeable parameters
On Tue, Oct 30, 2018 at 10:28:21AM -0600, Jan Beulich wrote: > >>> On 30.10.18 at 17:23, wrote: > > On Tue, Oct 30, 2018 at 08:44:20AM -0600, Jan Beulich wrote: > >> There's no guarantee that e.g. a switch() control expression's memory > >> operand(s) get(s) read just once. Guard against the compiler producing > >> "unexpected" code by sprinkling around some ACCESS_ONCE(). > >> > >> I'm leaving alone opt_conswitch[]: It gets accessed in quite a few > >> places anyway, and an intermediate change won't have any severe effect > >> afaict. > >> > >> Signed-off-by: Jan Beulich > > > > I'm curious how you came up with the list of parameters that need > > fixing. > > I've just gone through all that are currently run-time changable. Fair enough. Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] use consistent values when consuming runtime-changeable parameters
>>> On 30.10.18 at 17:23, wrote: > On Tue, Oct 30, 2018 at 08:44:20AM -0600, Jan Beulich wrote: >> There's no guarantee that e.g. a switch() control expression's memory >> operand(s) get(s) read just once. Guard against the compiler producing >> "unexpected" code by sprinkling around some ACCESS_ONCE(). >> >> I'm leaving alone opt_conswitch[]: It gets accessed in quite a few >> places anyway, and an intermediate change won't have any severe effect >> afaict. >> >> Signed-off-by: Jan Beulich > > I'm curious how you came up with the list of parameters that need > fixing. I've just gone through all that are currently run-time changable. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] use consistent values when consuming runtime-changeable parameters
On Tue, Oct 30, 2018 at 08:44:20AM -0600, Jan Beulich wrote: > There's no guarantee that e.g. a switch() control expression's memory > operand(s) get(s) read just once. Guard against the compiler producing > "unexpected" code by sprinkling around some ACCESS_ONCE(). > > I'm leaving alone opt_conswitch[]: It gets accessed in quite a few > places anyway, and an intermediate change won't have any severe effect > afaict. > > Signed-off-by: Jan Beulich I'm curious how you came up with the list of parameters that need fixing. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] use consistent values when consuming runtime-changeable parameters
On 30/10/18 14:44, Jan Beulich wrote: > There's no guarantee that e.g. a switch() control expression's memory > operand(s) get(s) read just once. Guard against the compiler producing > "unexpected" code by sprinkling around some ACCESS_ONCE(). > > I'm leaving alone opt_conswitch[]: It gets accessed in quite a few > places anyway, and an intermediate change won't have any severe effect > afaict. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] use consistent values when consuming runtime-changeable parameters
There's no guarantee that e.g. a switch() control expression's memory
operand(s) get(s) read just once. Guard against the compiler producing
"unexpected" code by sprinkling around some ACCESS_ONCE().
I'm leaving alone opt_conswitch[]: It gets accessed in quite a few
places anyway, and an intermediate change won't have any severe effect
afaict.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -256,7 +256,7 @@ int pv_domain_initialise(struct domain *
d->arch.pv.xpti = is_hardware_domain(d) ? opt_xpti_hwdom : opt_xpti_domu;
if ( !is_pv_32bit_domain(d) && use_invpcid && cpu_has_pcid )
-switch ( opt_pcid )
+switch ( ACCESS_ONCE(opt_pcid) )
{
case PCID_OFF:
break;
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -630,16 +630,16 @@ static void __putstr(const char *str)
static int printk_prefix_check(char *p, char **pp)
{
int loglvl = -1;
-int upper_thresh = xenlog_upper_thresh;
-int lower_thresh = xenlog_lower_thresh;
+int upper_thresh = ACCESS_ONCE(xenlog_upper_thresh);
+int lower_thresh = ACCESS_ONCE(xenlog_lower_thresh);
while ( (p[0] == '<') && (p[1] != '\0') && (p[2] == '>') )
{
switch ( p[1] )
{
case 'G':
-upper_thresh = xenlog_guest_upper_thresh;
-lower_thresh = xenlog_guest_lower_thresh;
+upper_thresh = ACCESS_ONCE(xenlog_guest_upper_thresh);
+lower_thresh = ACCESS_ONCE(xenlog_guest_lower_thresh);
if ( loglvl == -1 )
loglvl = XENLOG_GUEST_DEFAULT;
break;
@@ -690,13 +690,14 @@ static int parse_console_timestamps(cons
static void printk_start_of_line(const char *prefix)
{
+enum con_timestamp_mode mode = ACCESS_ONCE(opt_con_timestamp_mode);
struct tm tm;
char tstr[32];
uint64_t sec, nsec;
__putstr(prefix);
-switch ( opt_con_timestamp_mode )
+switch ( mode )
{
case TSM_DATE:
case TSM_DATE_MS:
@@ -704,7 +705,7 @@ static void printk_start_of_line(const c
if ( tm.tm_mday == 0 )
/* nothing */;
-else if ( opt_con_timestamp_mode == TSM_DATE )
+else if ( mode == TSM_DATE )
{
snprintf(tstr, sizeof(tstr), "[%04u-%02u-%02u %02u:%02u:%02u] ",
1900 + tm.tm_year, tm.tm_mon + 1, tm.tm_mday,
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
