From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (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 F164E38DC5C for ; Fri, 21 Aug 2026 09:41:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787305282; cv=none; b=caijQCp57kkJteBob8tkQ1RdJ6IsNihw2GSDKo5S9PTY7affIAdF71kImzHr5OW9gU3r9A7zKoiEtt+aQjWY2WbWShmGiwhCb1GmUqIIkitducF+10qioiiwqBUJxJ7oLK0oPIsUsgqM1JwvZPqT+TmY3h1VmEW3yzYm1jTKgPQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787305282; c=relaxed/simple; bh=MDuA7Ky/0oeqZYNprkCuTnPM6OQk5mo/pbNCOuCI3Ao=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rRz9N8+rq6JWhU3Xal1YCWmhDgWCBFG8go8rMv7nC4N5EtR8G1L+ZJmPMcep/HcVgFiYz8mCOJOHREJjT1erTtI0VHwpDYH28/x5u0f7lA509eX4kPXZ5whSjTz7Jwi4/kbnVk7VoGqBgaIEoOSQBYw3KYXX8FzhAshMm9Cqzv0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=Dcb3MIkd; arc=none smtp.client-ip=209.85.128.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="Dcb3MIkd" Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-499ac87c92bso6510825e9.1 for ; Fri, 21 Aug 2026 02:41:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1787305266; x=1787910066; darn=vger.kernel.org; h=user-agent:in-reply-to:content-disposition:content-type :mime-version:references:message-id:subject:cc:to:date:from:from:to :cc:subject:date:message-id:reply-to:content-type; bh=z2vT4G4w+FuGaSUg7rJCxX3eISYj4wJ+Berx4Gi99f8=; b=Dcb3MIkdjCrE0U/d3jV9oEkfke4NvwATPfkZVJWt9+h8alEE4C44wQ28PVks3t/13C R+C5raffKUA2E1qaWd6/0CJEG6kOBvewT+nfS6zxt7MmT+Km0SqbstDcH8rg1+tTBZGQ lj7ah1c+lAEEsIgQCy3ozvyMgRrML8eykopcNTFExH3S5ArR7SBifg5ZdBkQ9hIdihJa +BMcCENaYsJo15jCG5JmAqqBTa5j2GvTVSAKAp/P8ZLeOlkGvprWbL0dHDu20Rzhu8um o8/7aCEgzOeycrOGjnlq5FgwVJ1C7W9cN2kyYcwla81GPC5mZrMyEwAwxVzMLHXruWuu fZEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787305266; x=1787910066; h=user-agent:in-reply-to:content-disposition:content-type :mime-version:references:message-id:subject:cc:to:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=z2vT4G4w+FuGaSUg7rJCxX3eISYj4wJ+Berx4Gi99f8=; b=a1OcO5mzBgTgp6ArMC1GzRHjjBvhxO68cTNRLrVc24BDveB5GHJGJEjR0Lhw5PSaie zWdeHmCuyxVSjTzf9xpJoSN8dKAzzzk/2559rLNPGz05x/5/bMaqrukVk8TWEZpdamym ZZl7J3ZIW/VlLVWT8qJ+6obrAAfCsJJUoxyXChQ9M0xvKPvTuzupRibwIdzecIzkeKEg AUx0xzxy5DqqVVuSQ1VrpHdO1XjFhvAMacgeEpVQCt4EnsD2bmOyQtgAcuZYeVhCEWe/ vigSreln5c60f+6F9Dl9ZRA8gXRK7918K4IFljjoiV20d0LD6RjxuSoj06xi4h7Tibej ZpYA== X-Forwarded-Encrypted: i=1; AHgh+Rpvxwv2xTN2h3ET5ZtplfnOxN/fW4XmHqHJIGi6RSjRqLrOwj8yRog7D1lPR6McnvR/y5oH8wbXRKLBWeE=@vger.kernel.org X-Gm-Message-State: AOJu0Yz4bUfMu/qLvgTQp04mk4TcWeweMtwzdMWy3SALYWNMXYS2lOTq yJaNd9lxTVC9BnWUtsgvAhcrEC9bOBWDzTQqFGfXcb6x9fOB4wZfhUu3RgZeBB2azsc= X-Gm-Gg: AR+sD1243lnwKKuVQOjrMMknOgcyu02bf5g+JU2T48iaQu5XbfDDSIy5nLc/TQZ5B/T 4KNcO+UnXPKo8ap7xpWrLZPgCxuB/K4MBNuYq4vTAj9QpxgXO/nPqEK93k34jQLVDOQsbY+V/A6 61oyXTq3Q/tK5Lnk+RwVrx+DLHRrQTGvoDzU92/s1XxP2J70KALKleQcbVNqOkkg5YNCaZ3En/c VeL92oG0pauWyIEfaS5PXe2RC1gTqsEzAZyDoWs8Suefjxzjoy++DdQbsNbOSds73uHE2D/j0CV FAeoAT14AVcq/s4bs11cREC/MtWsergeR6UJYGiixvIWNAzD5DvWw/GSCTJmKgkwx0c6cNub1MJ jIxNUXmqubIluwtTJOFp0mylmZKTnzi6Vvo2g3/zGk6h5HDbVJxpspdNp33Au2vl8fhW3kbXYKB rqe4kD/O32o7qR1jOCGEcYLGrNUjL7PkBUlmbobMDqRU3at39DmpV7NrOPvItv5bSUU5r8gc7dW 6ZYZE0LeBGnDEhI2ADCCIgcvXPmxnQxmipDrtPeIg== X-Received: by 2002:a05:600c:c493:b0:499:737c:8a8b with SMTP id 5b1f17b1804b1-499b847746fmr65154955e9.12.1787305266266; Fri, 21 Aug 2026 02:41:06 -0700 (PDT) Received: from r1chard (61-231-75-38.dynamic-ip.hinet.net. [61.231.75.38]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-395c46ca8b6sm2643642a91.8.2026.08.21.02.41.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Aug 2026 02:41:05 -0700 (PDT) From: Richard Lyu X-Google-Original-From: Richard Lyu Date: Fri, 21 Aug 2026 17:40:59 +0800 To: Jarkko Sakkinen Cc: Thomas Fourier , stable@vger.kernel.org, Peter Huewe , Jason Gunthorpe , Jerry Snitselaar , "open list:TPM DEVICE DRIVER" , open list Subject: Re: [PATCH] tpm: Fix barriers to prevent hwrng from activating during resume Message-ID: References: <20260803092240.18348-2-fourier.thomas@gmail.com> 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; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.2.16 (2025-11-22) >> memory reordering between the wake up and clearing the flag is allowed. When exactly can this reordering happen? >> diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c >> index 12b7394b34bd..7f500797b7a7 100644 --- a/drivers/char/tpm/tpm-chip.c >> +++ b/drivers/char/tpm/tpm-chip.c @@ -173,6 +173,9 @@ int >> tpm_try_get_ops(struct tpm_chip *chip) if (chip->flags & >> TPM_CHIP_FLAG_SUSPENDED) goto out_lock; >> >> + /* Ensure that device is fully resumed */ >> + rmb(); >> + >> rc = tpm_chip_start(chip); >> if (rc) >> goto out_lock; Where inside tpm_chip_start do we actually need to avoid loading a stale state or flag? >> diff --git a/drivers/char/tpm/tpm-interface.c >> b/drivers/char/tpm/tpm-interface.c index f745a098908b..2de12b02f62b 100644 >> --- a/drivers/char/tpm/tpm-interface.c +++ >> b/drivers/char/tpm/tpm-interface.c @@ -474,13 +474,12 @@ int >> tpm_pm_resume(struct device *dev) if (chip == NULL) return -ENODEV; >> >> - chip->flags &= ~TPM_CHIP_FLAG_SUSPENDED; >> - >> /* >> * Guarantee that SUSPENDED is written last, so that hwrng does not >> * activate before the chip has been fully resumed. >> */ >> wmb(); >> + chip->flags &= ~TPM_CHIP_FLAG_SUSPENDED; > >Can you rationalize this change? I agree the clearing of the flag should be moved after wmb() to guarantee that SUSPENDED is written last, the flag has to be cleared after the barrier. That part makes sense. My remaining question is whether we actually need the wmb() barrier here?