linux-kernel - Re: [RFC Patch v1 2/3] cxl/pci: Update Port GPF timeout only when the first EP attaching

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: <20250321054007.fidkwiemotwqyui3@offworld>
Date: Thu, 20 Mar 2025 22:40:07 -0700
From: Davidlohr Bueso <dave@...olabs.net>
To: Li Ming <ming.li@...omail.com>
Cc: jonathan.cameron@...wei.com, dave.jiang@...el.com,
	alison.schofield@...el.com, vishal.l.verma@...el.com,
	ira.weiny@...el.com, dan.j.williams@...el.com,
	linux-cxl@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC Patch v1 2/3] cxl/pci: Update Port GPF timeout only when
 the first EP attaching

On Wed, 19 Mar 2025, Li Ming wrote:

>If a CXL switch is under a CXL root port, The Port GPF Phase timeout
>will be updated on the CXL root port when each cxl memory device under
>the CXL switch is attaching. It is possible to be updated more than
>once. Actually, it is enough to initialize once, other extra
>initializations are redundant.

It's actually not updated more than necessary because update_gpf_port_dvsec()
checks first:

	if (FIELD_GET(base, ctrl) == GPF_TIMEOUT_BASE_MAX &&
	    FIELD_GET(scale, ctrl) == GPF_TIMEOUT_SCALE_MAX)
		return 0;

>When the first EP attaching, it always triggers its ancestor dports to
>locate their own Port GPF DVSEC. The change is that updating Port GPF
>Phase timeout on these ancestor dports after ancestor dport locating a
>Port GPF DVSEC. It guaranttess that Port GPF Phase timeout updating on a

s/guaranttess/guarantees

>dport only happens during the first EP attaching.

... but yeah, I think this is still better, logically.

Reviewed-by: Davidlohr Bueso <dave@...olabs.net>

(with the caveat that if patch 1 is not necessary then this would need to
be redone).