[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20151105164820.GF32247@leverpostej>
Date: Thu, 5 Nov 2015 16:48:20 +0000
From: Mark Rutland <mark.rutland@....com>
To: Stefano Stabellini <stefano.stabellini@...citrix.com>
Cc: xen-devel@...ts.xensource.com, linux@....linux.org.uk,
Ian Campbell <ian.campbell@...rix.com>, arnd@...db.de,
marc.zyngier@....com, catalin.marinas@....com,
konrad.wilk@...cle.com, will.deacon@....com,
linux-kernel@...r.kernel.org, olof@...om.net,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v11 1/5] xen: move xen_setup_runstate_info and
get_runstate_snapshot to drivers/xen/time.c
Hi,
> +static u64 get64(const u64 *p)
> +{
> + u64 ret;
> +
> + if (BITS_PER_LONG < 64) {
> + u32 *p32 = (u32 *)p;
> + u32 h, l;
> +
> + /*
> + * Read high then low, and then make sure high is
> + * still the same; this will only loop if low wraps
> + * and carries into high.
> + * XXX some clean way to make this endian-proof?
> + */
> + do {
> + h = p32[1];
> + barrier();
> + l = p32[0];
> + barrier();
> + } while (p32[1] != h);
I realise this is simply a move of existing code, but it may be better
to instead have:
do {
h = READ_ONCE(p32[1]);
l = READ_ONCE(p32[0]);
} while (READ_ONCE(p32[1] != h);
Which ensures that each load is a single access (though it almost
certainly would be anyway), and prevents the compiler from having to
reload any other memory locations (which the current barrier() usage
forces).
> +
> + ret = (((u64)h) << 32) | l;
> + } else
> + ret = *p;
Likewise, this would be better as READ_ONCE(*p), to force a single
access.
> +
> + return ret;
> +}
> + do {
> + state_time = get64(&state->state_entry_time);
> + barrier();
> + *res = *state;
> + barrier();
You can also have:
*res = READ_ONCE(*state);
That will which will handle the barriers implicitly.
Thanks,
Mark.
> + } while (get64(&state->state_entry_time) != state_time);
> +}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists