Re: [PATCH v10 05/10] iommu/amd: Introduce helper function to update 256-bit DTE
From: Arnd Bergmann
Date: Wed Nov 13 2024 - 07:55:00 EST
On Wed, Nov 13, 2024, at 13:03, Suravee Suthikulpanit wrote:
>
> +static void write_dte_upper128(struct dev_table_entry *ptr, struct
> dev_table_entry *new)
> +{
> + struct dev_table_entry old = {};
> +
> + old.data128[1] = __READ_ONCE(ptr->data128[1]);
The __READ_ONCE() in place of READ_ONCE() does make this a
lot simpler. After seeing how it is used though, I wonder if
this should just be an open-coded volatile pointer access
to avoid complicating __unqual_scalar_typeof() further.
> + do {
> + /*
> + * Preserve DTE_DATA2_INTR_MASK. This needs to be
> + * done here since it requires to be inside
> + * spin_lock(&dev_data->dte_lock) context.
> + */
> + new->data[2] &= ~DTE_DATA2_INTR_MASK;
> + new->data[2] |= old.data[2] & DTE_DATA2_INTR_MASK;
> +
> + /* Note: try_cmpxchg inherently update &old.data128[1] on failure */
> + } while (!try_cmpxchg128(&ptr->data128[1], &old.data128[1],
> new->data128[1]));
Since this is always done under the lock, is there ever
a chance that the try_cmpxchg128() fails? I see that the
existing code doesn't have the loop, which makes sense
if this is just meant to be an atomic store.
Arnd