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

Re: [Xen-devel] [PATCH 1/4] xen/spinlocks: in debug builds store cpu holding the lock

On 08.08.19 12:28, Julien Grall wrote:

On 08/08/2019 08:51, Juergen Gross wrote:
On 08.08.19 08:58, Jan Beulich wrote:
On 07.08.2019 16:31, Juergen Gross wrote:
Do we have an implied assumption somewhere that unsigned short is
exactly 16 bits wide? I think "val" wants to be uint16_t here (as
you really mean "exactly 16 bits"), the two boolean fields want
to be bool, and the remaining two ones unsigned int.

But that would increase the size of the union to 4 bytes instead of 2.
So at least pad and cpu must be unsigned short or (better) uint16_t.

How about bool irq_safe:1?

I didn't question that, but OTOH I'm not sure doing something like:

struct {
  bool     unseen:1;
  bool     irq_safe:1;
  uint16_t pad:2;
  uint16_t cpu:12;

is guaranteed to be 2 bytes long. I think pad will be still put into the
first byte, but the compiler might decide that the 4 bits left won't be
able to hold the next 12 bits so it could start a new uint16_t at offset

Moving the bool types to the end of the struct would avoid that IMHO.


Xen-devel mailing list



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