linux-kernel - Re: [PATCH v10 05/10] iommu/amd: Introduce helper function to update 256-bit DTE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <cac1ccd3-4b81-4374-a49d-9afad755b19c@app.fastmail.com>
Date: Wed, 13 Nov 2024 13:50:14 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Suravee Suthikulpanit" <suravee.suthikulpanit@....com>,
 linux-kernel@...r.kernel.org, iommu@...ts.linux.dev
Cc: "Joerg Roedel" <joro@...tes.org>, "Robin Murphy" <robin.murphy@....com>,
 vasant.hegde@....com, "Uros Bizjak" <ubizjak@...il.com>,
 Linux-Arch <linux-arch@...r.kernel.org>, "Jason Gunthorpe" <jgg@...dia.com>,
 "Kevin Tian" <kevin.tian@...el.com>, jon.grimm@....com,
 santosh.shukla@....com, pandoh@...gle.com, kumaranand@...gle.com
Subject: Re: [PATCH v10 05/10] iommu/amd: Introduce helper function to update 256-bit
 DTE

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