From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 72E6A2749DC for ; Mon, 5 Jan 2026 18:12:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767636725; cv=none; b=dOrjqdx9n9ML2bC6EJmNBRngSxVPLT/+NOI3Oi2HFkvmC4ujYP70gSS0QZ1s0dHftDwO0XbavEviy6OHpOo8BzN8JVMmkUr7d6JVvjzL6EseaJ3n6Ycl0HJwvtgCzm3ppZ6xF5OGu2SjYzL02rcDQuZTzXM/Ev8054lZKIQ27/Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767636725; c=relaxed/simple; bh=OCb3A1WFzV0w5ZbO/H402vOffTteqscuLBNvsEalcXI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MKK5eNIcgO/6BmKDpeI6zomMgERE7QvdYd+1GqBOW1YLBR0zmAZgPEqY6fL8aqD0a8M3RUQb5f1Vj3rQUajJow8t9V8RedavRbK/h52SVqWVw45b93LlPl4tSotnu+4P6cCiDaQVEzMq2kHMauAHphNK/aQ51SvOKJzRJZnA5xQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=oMUp/xwj; arc=none smtp.client-ip=209.85.160.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="oMUp/xwj" Received: by mail-qt1-f179.google.com with SMTP id d75a77b69052e-4f1aecac2c9so1832391cf.1 for ; Mon, 05 Jan 2026 10:12:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1767636722; x=1768241522; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=RNoRn5xn2oaDC2IYtqhOSxgeOL9snP+iopTS7Mlk9mY=; b=oMUp/xwj+GOQPBfhZ/UM6R1L8+qWNMG7qQdUxzr92m/5qyD4lbdelv+qQq4KACGhAf MHw+Kfb/LdNwXceb2J0ok3P/BqX9I5mIbV0ginCVbznoX7LwkNt8Y7FIOtqcAQCRXeEJ Wc0mZQRZBaIdA1PUY43qnGjVhqWHa7WYmfKIJVOuQf5eS5p6XUa+3iK/3GJ2t+ZqwCM5 X6JDw9MsGAm0/qwFrni/NJzeFLa6FEQLC5b3Lz/kfOsf6A3OhAMSBo1AkDrnlA0EPIzb LV30rIkG0Bdk4/nMFSDtBoY7d7HFwH6/8eFtvhXvjvXzry7o+rfUnV7YblegqEFBocxN /tmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767636722; x=1768241522; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=RNoRn5xn2oaDC2IYtqhOSxgeOL9snP+iopTS7Mlk9mY=; b=ct7C+mJNW12dvxXYaN8M59PBJKujxf54h15t8wvJVzJjtV5UJFAdaGdeIS76Mg+UMv /uNt/jrY7gc/MbKdLQR22+iD1goyMHUHNPIUATjJH/ztuacaJYTHlehBBKlziAghdxD+ jv6T0LAfAfZm6D/NQ8PjnxvcCfvCm57Ii4a7LE6+i3MaB4cKFvKRxRl0kpcD9Y2fKrWM el4Io1q+ca9NqcvcIl1b/puAWJ4goJM0LxEz58isWTqOxWhmWJrtDDfhMmwij83Ktz+r JZdCWhbPUU0/fqcc6dNoVbpkGQPFnth0OLoALy5LTFJJptMXzWKP1A1JcewDTtHUTEGM IcPg== X-Forwarded-Encrypted: i=1; AJvYcCWSDbX211adb3b4qBzT29pr1s4Gq4xuVGsCQROvYBFpbV2xQH9vtQs5DiGlTwiguaUTwX5X5j4neGXdEFc=@vger.kernel.org X-Gm-Message-State: AOJu0Yybsq1pjMso1D/bekNYXRl1/juaBmn+ACcAb1uM6+sslAl+Mn/j smSkYxoDh0jZrBdIgCTKCe/MuUDpFmNpdNR1obwOK3e1czPqqZ2ht6LaUob84m+Y0C8= X-Gm-Gg: AY/fxX5LGy9jDINOHej6ckfGQ5IaIjTU7zM8Fc7AEtg/z7PIKwavYvBFVmWh/K22xRQ LJznP5FxDOVRclfIcmHX6G9llixrEulJaGqa5eOvPb12IcLOuIYvZYSirMLPGDlnLb5HZAJ/ByT 4N//lnp3El/53I2GgQLaY3w5Mj9ZZ4a5YZBGQ8QU2szJpEcZ3Dg4VtJR0YTjFNDk7KEugEH0OO2 9mUxbr3qw4EzoITBevcQ6kEXth/FBYucOfsEkse8PVsg1nhGidBqIR9Lnf6FbUvNj4rOLWksoTI 84gcZS0s/Afd+ROpMO/IWetcrgdxcuRF2IX672LQp5TCuUWNj3MC2ZgcubZVAAjpoIEoh5dtwmQ AxF+Zx0W93wt3JVoQwN/zUdE4e0aw1Vk61k4jAMipuOXMLRvfYqIbVqLx+WJyJ7WW3NRHB3oCe6 4S1ETBmtgKtLdLi6nJedGNHpEedSuneHCTroqBn3rncRErzeEL1Susj2CcbxwitH9c2tKrt24r/ L4j4g== X-Google-Smtp-Source: AGHT+IG3qj9OottVfFav2AogQtpKbbanpaAujF7w0LodjQe+bZqnAMPWgOXRjmlvmo/4kgErrL/wuw== X-Received: by 2002:ac8:5f09:0:b0:4ff:519c:f478 with SMTP id d75a77b69052e-4ffa83bc599mr1094121cf.1.1767636722055; Mon, 05 Jan 2026 10:12:02 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-162-112-119.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.112.119]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-4ffa7056f18sm3363511cf.1.2026.01.05.10.12.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Jan 2026 10:12:01 -0800 (PST) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1vcp3g-00000001BhV-2dYQ; Mon, 05 Jan 2026 14:12:00 -0400 Date: Mon, 5 Jan 2026 14:12:00 -0400 From: Jason Gunthorpe To: Dmytro Maluka Cc: David Woodhouse , Lu Baolu , iommu@lists.linux.dev, Joerg Roedel , Will Deacon , Robin Murphy , linux-kernel@vger.kernel.org, "Vineeth Pillai (Google)" , Aashish Sharma , Grzegorz Jaszczyk , Chuanxiao Dong , Kevin Tian Subject: Re: [PATCH v2 0/5] iommu/vt-d: Ensure memory ordering in context & root entry updates Message-ID: <20260105181200.GH125261@ziepe.ca> References: <20251227175728.4358-1-dmaluka@chromium.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20251227175728.4358-1-dmaluka@chromium.org> On Sat, Dec 27, 2025 at 06:57:23PM +0100, Dmytro Maluka wrote: > As discussed in [1], we don't currently prevent the compiler from > reordering memory writes when updating context entries, which is > potentially dangerous, as it may cause setting the present bit (i.e. > enabling DMA translation for the given device) before finishing setting > up other bits in the context entry (and thus creating a time window when > a DMA from the device may result in an unpredicted behavior). > > Fix this in the same way as how this is already addressed for PASID > entries, i.e. by using READ_ONCE/WRITE_ONCE in the helpers used for > setting individual bits in context entries, so that memory writes done > by those helpers are ordered in relation to each other (plus, prevent > load/store tearing and so on). > > While at it, similarly paranoidally fix updating root entries as well: > use WRITE_ONCE to make sure that the present bit is set atomically > together with the context table address bits, not before them. The PASID entries should not be manipulated 'livel' in a haphazard way like this in the first place! Like AMD and ARM build the new PASID entry on the stack and then it should be copied to the DMA'able memory in a way that is consistent with the HW's atomicity granual, paying attention not to 'tear' it. This manipulate-in-place is just asking for trouble, and can never support replace or full viommu requirements.. :\ So while it is perhaps an improvement to do this work, it would be better to fix the root cause issue if someone has time.. Jason