From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2047C1F4180 for ; Fri, 24 Jul 2026 23:08:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784934536; cv=none; b=RtYck79HDXxZmh0ByyVUSYSGk5wH06OGvXPbQS+ywjhmfxtjAe5vDkqZIs4gOputTtQkH6nqmdMJI1+f9vXPUJqIC1mmkOOUoDhWuTt0zzj6jQqs0YhUVUHLaPIRRgLeH0LGNvbfkFZOog/zH+GekVoGOigAUUjXrYLxHeKNiPY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784934536; c=relaxed/simple; bh=zzz0lISZNVntjqe+EAErT59dRiLxoNvMxqtjxNNNHgk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=oCQ9QqpZqYPtVWyC9WiMH9538WzZBYbtuxPiinMUOynJc7vnqrcc9x2aNh7kEZfjmDjMHCxA6EJczAWa/exKs1VORWZ13jZ8ckujcQgk1lgOqFAoBY1OhZ3OeD5O4lxukUHf1vEbu2VlBWL8yD6v4DhWB/LpSn18HRG/iKVYTBs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=pqyA4/Mr; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=UjTqpDy/; arc=none smtp.client-ip=205.220.180.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="pqyA4/Mr"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="UjTqpDy/" Received: from pps.filterd (m0279873.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 66OKxM4k4164522 for ; Fri, 24 Jul 2026 23:08:52 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= zp2tfSR+bjxwjoNPBDl5LFXAazKI/qflQFGUbCSQV7A=; b=pqyA4/MrdLWTgopl PVab4LJwEeVARuk+OfvsUuVHHQByBfV8hSmZguPC5rkdP++quW9HbFWNl/srotEQ UiboXwO7h0c9vRo86r7neTqCjXWITWv4TOJ6NQfY3Jn1soxZAhU0OxKhprEKZYvK FV4yazkObOHrv9x+DHdz1v6+20C9Q79+hCtKjre9+uF4SHt4Vmb0Z+oZKrYGXe2O CEFa/pakLWYGQ4GnWnBZFCOzWdsTnYicZ7xw4SS5QqkwVdqoFzEvOvCTdbbj3Co3 1ahE2t8MYMZMetCcCvYDzRUbuPij0fCxY35smNoBrLnn5cmm6du1AUtRc6s8ilwg LZB+mA== Received: from mail-pg1-f197.google.com (mail-pg1-f197.google.com [209.85.215.197]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4fm5yajusn-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 24 Jul 2026 23:08:52 +0000 (GMT) Received: by mail-pg1-f197.google.com with SMTP id 41be03b00d2f7-ca860baea9fso1835771a12.2 for ; Fri, 24 Jul 2026 16:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1784934531; x=1785539331; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=zp2tfSR+bjxwjoNPBDl5LFXAazKI/qflQFGUbCSQV7A=; b=UjTqpDy/mJjGOsb5LbuWulm50Q8xDupbo1GqCybyfZKV1OK+CvbP5KyJEeVAD55dzD A578WVVccPws0h0l8SCCB+b3wRnA/PHzkcOsMaVH5q88idBmlWZja1z5MOttqsz1rb3g 7x3yKnSux5qy+OUicgRTK55mgm0/OzTu5azRW2dOr74HdSFNb2tX1lhT+2fM9MvUXCCO w3mg41aAhhlHpXIlyPWnGX/SB5kr9AR3c2aMw/+b3i4WagG1gPqQ6KC3y35LQ+yTSETz xGfgHEYtR3Hyg3W3Mj58s7YoYtQU9T6fEgi4Hybsxf9QEUEMudz1/jUQ60uRAcJ+VlMp iV/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784934531; x=1785539331; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=zp2tfSR+bjxwjoNPBDl5LFXAazKI/qflQFGUbCSQV7A=; b=iPtb5RdQYDcAqzjzQqSrt0E+S9bpRsl0NYMREKiTR6uRdvYLVVK66tgggWSg0AxfII dvk2CGf2ZW8H8IDN0DVERrpB6Htdjrh53zONwq8yM9EQ6k2eLZiJCx5aQFjCinim8Lbn vmPhT8rDFmdb0jK2vySCbkTzoeb6BJblFCRDqRmwxake/wQ6hkt8SlkjFXwjgnzOKWk0 /sIcDbY4Gug4wfn9oFINGIehBkHlmz4zHyuCidD2ATq1e1QAVjLrut6qG+POobXmZKEq +yL7cmgN3Iyt8uU37PjYEV/UCDzRLpSvRlEXKSBhLsb2Y11Dzjoov62qiFoQo3tvv26Z 9iVw== X-Forwarded-Encrypted: i=1; AHgh+RoL809S73Mt1xCs9/TLdVoiBBwW37chXpX+fyOmYIUpvWy70CmSIGll2Na9XBcg7h+V1k0lsFbx45T7gPQ=@vger.kernel.org X-Gm-Message-State: AOJu0Yw4GlcO5JbejLyCfCfK9rjl0W5YFU9N7y7/0G7X2yZ1KSrwBTnP iZQ/EANul1xaskVqZs+e6NYMYlObEL97AxkbPROkDdnQqn+GRO3BWXdyT3x35o6Q+wBLF67I5hB TPffd0syT+Ia/Rj55brX50hoLzUk/PKbdldjVXR/drlAyL/UHz60we0XOINwi9LgoLHV8Z5xwsw 4= X-Gm-Gg: AR+sD12kiGg1e+blYgy/YmKlw6zrypSM+XTI3RU4R8dErPfY049ZpgX4ImVJDKnNle+ vw6PRClvYJXZgH/P/JyaL4nao+Trx7wiVH0YsUvwTMLLs6qSq+0kglbXcwl+K0iL7+BRUpQZQV+ Rs49hvF1YrrB/2j1eGK1r5A4N0cAbTqBseHgBjO7AO4Dtod+g08aSYeukONOdbOCRscArDduWiY kAg+ac3BJL1ql21r87yUFLsPlq+CVLGkQRsjWa5Nhtc11m+hcxbe95kGl8Z/9BaR/zpAIHOZULC 7NeqBBOdearmhZUpvJAArUGmSnoadmcT/7NzwQqOCX6Cdv0c/Hncu9CsFxcY9AexAZjCXhhi2oW oQjt7J6MZ1JbK1RE/dXQoZLIBA9flqA== X-Received: by 2002:a05:6a21:6817:b0:3b4:8bc6:138 with SMTP id adf61e73a8af0-3c67da72a1dmr346156637.23.1784934531414; Fri, 24 Jul 2026 16:08:51 -0700 (PDT) X-Received: by 2002:a05:6a21:6817:b0:3b4:8bc6:138 with SMTP id adf61e73a8af0-3c67da72a1dmr346121637.23.1784934530974; Fri, 24 Jul 2026 16:08:50 -0700 (PDT) Received: from [192.168.4.47] ([76.167.171.193]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-314bc584433sm2956074eec.23.2026.07.24.16.08.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Jul 2026 16:08:50 -0700 (PDT) Message-ID: Date: Fri, 24 Jul 2026 16:08:49 -0700 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] cxl/hdm: Enforce CFMWS memory type policy at decoder commit time To: Dave Jiang , linux-cxl@vger.kernel.org Cc: dan.j.williams@intel.com, ira.weiny@intel.com, vishal.l.verma@intel.com, alison.schofield@intel.com, linux-kernel@vger.kernel.org References: <20260711003341.2602368-1-mayank.rana@oss.qualcomm.com> <61531e60-0171-4d7e-b61b-ac0790a38ede@intel.com> <115d2157-d4d2-4897-a9c8-fe42fec0bbf9@oss.qualcomm.com> <41540b44-8142-4b80-b876-0ff3f7ddd619@oss.qualcomm.com> Content-Language: en-US From: Mayank Rana In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Proofpoint-Spam-Info: AW1haW4tMjYwNzI0MDIwOCBTYWx0ZWRfX0R1N5pvZkJga R3yKbJJZmmBIPAqvpDHdp09l6H4KusuNm2mX9fm/3oXJclRumjie1BqPOWhyUnFe+K30P0iB0Dw K/vDKQ22iKQb0TwL9lX/o4znZNKPU4Y= X-Authority-Analysis: v=2.4 cv=Rtz16imK c=1 sm=1 tr=0 ts=6a63f084 cx=c_pps a=rz3CxIlbcmazkYymdCej/Q==:117 a=aHhNPKUfMHGsajXC+q458A==:17 a=IkcTkHD0fZMA:10 a=RAioF0-LDSMA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=rJkE3RaqiGZ5pbrm-msn:22 a=EUspDBNiAAAA:8 a=qlVHQRLn26njG4ZrRUEA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=bFCP_H2QrGi7Okbo017w:22 X-Proofpoint-GUID: ZU0zOVfA02YKG37AjNexODlkQw0gqzwL X-Proofpoint-ORIG-GUID: ZU0zOVfA02YKG37AjNexODlkQw0gqzwL X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNzI0MDIwOCBTYWx0ZWRfX1HBF2X4Op9KP kUG1G2RSczPhWshdru7f2BQHhnJtqpUghHmmEJS+QKQgL0kS03bDZ9YmN+SXEn6x6xzPDxCrc/F th6+kpDQ/hDK8x6W/3in+Ny0+V1GKUWgtizquc0oI4+0JJ7IJMKGM50ZMP8m0GrTdBeeNapl5AZ ctUAv7pcWaSAUzVDjFLqNdnll+Z/MWe0VjlGw9vY0kCbBkjMNUL1iGlf0uMIEUY0D0yq3iChMN3 WvNVrntzb8i0Lao3MSMusDkfJzC5SgOAyjjrx3g5Tsd2TknaMttXgOpBrMeQzLfqSPvPIIbNdmM NpHhp2n8OsxBURQgScTKFW2Fvr2F0sufn5EbjZZk5bR1wjGhf7eg1wk9gyiXLAThIeN+tWWha6C mQun1mnvVm8BXcNnCP0zjwbrJB3GZENSNHCPleEWfCIenCRNNBncEhZxns15u5IVd7w6jFLGb9X 4SAMy6LCCB5pi0YF5Ew== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-07-24_05,2026-07-24_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 phishscore=0 priorityscore=1501 suspectscore=0 lowpriorityscore=0 bulkscore=0 spamscore=0 malwarescore=0 clxscore=1015 adultscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2607240208 Hi Dave On 7/23/2026 4:47 PM, Dave Jiang wrote: > > > On 7/23/26 4:18 PM, Mayank Rana wrote: >> Hi Dave >> >> On 7/15/2026 3:26 PM, Mayank Rana wrote: >>> Hi Dave >>> >>> Thank you for review comments. >>> >>> On 7/13/2026 8:47 AM, Dave Jiang wrote: >>>> >>>> >>>> On 7/10/26 5:33 PM, Mayank Rana wrote: >>>>> A CXL Fixed Memory Window Structure (CFMWS) in the ACPI CEDT table >>>>> carries a restrictions field that describes the memory types a platform >>>>> window supports.  cfmws_to_decoder_flags() translates this into >>>>> CXL_DECODER_F_TYPE2 (HDM-DB permitted) and CXL_DECODER_F_TYPE3 (HDM-H >>>>> permitted) flags on the root decoder. >>>>> >>>>> However, nothing currently prevents a caller from committing an endpoint >>>>> or switch decoder whose target_type conflicts with the CFMWS policy: >>>>> >>>>>    - A decoder with target_type == CXL_DECODER_DEVMEM (HDM-DB) can be >>>>>      committed on a window that lacks CXL_DECODER_F_TYPE2 (HDM-H only). >>>>>      A dual-capable device will accept HOSTONLY=0 + COMMIT=1 without >>>>>      asserting COMMIT_ERROR, silently violating platform policy. >>>>> >>>>>    - Symmetrically, a decoder with target_type == CXL_DECODER_HOSTONLYMEM >>>>>      (HDM-H) can be committed on a window that lacks CXL_DECODER_F_TYPE3 >>>>>      (HDM-DB only), again violating ACPI CFMWS restrictions. >>>>> >>>>> Add a check in cxl_decoder_commit() that walks from the decoder's >>>>> assigned region to the root decoder and rejects the commit with >>>>> -EOPNOTSUPP if the decoder's target_type requires a capability flag that >>>>> the CFMWS window does not advertise: >>>>> >>>>>    - CXL_DECODER_DEVMEM      requires CXL_DECODER_F_TYPE2 on root decoder >>>>>    - CXL_DECODER_HOSTONLYMEM requires CXL_DECODER_F_TYPE3 on the root >>>>>      decoder >>>>> >>>>> required_flag is initialized to zero so that any future target_type >>>>> values not covered by the if/else-if chain leave the enforcement check >>>>> a no-op via the leading required_flag && guard. >>>>> >>>>> This makes the CFMWS restrictions field authoritative for memory type >>>>> enforcement in both directions, regardless of individual device capability. >>>>> The existing COMMIT_ERROR path in cxld_await_commit() remains as a >>>>> secondary safeguard for devices that cannot support the requested mode. >>>> >>>> Can you please trim the commit log? The AI generated verbiage is excessively wordy. A simple and more to the point short log that conveys all the information would be appreciated. >>> ok. noted down. >>>>> >>>>> Fixes: 3e23d17ce198 ("cxl/acpi: Use the ACPI CFMWS to create static decoder objects") >>>>> Assisted-by: Claude:claude-sonnet-4-6 >>>>> Signed-off-by: Mayank Rana >>>>> --- >>>>>    - Initialize required_flag = 0 and use explicit else-if for >>>>>      CXL_DECODER_HOSTONLYMEM; guard enforcement with required_flag && >>>>>      so unknown target_type values skip the check cleanly >>>>> >>>>> Changes in v2: >>>>>    - Extend enforcement to cover both directions: HDM-H commits on >>>>>      HDM-DB-only windows are now rejected in addition to HDM-DB commits >>>>>      on HDM-H-only windows (reported by Sashiko AI review) >>>>>    - Generalize condition from single DEVMEM check to type-dispatch >>>>>      selecting required_flag based on target_type >>>>>    - Update commit message and subject to reflect bidirectional policy >>>>> >>>>> Testing >>>>> ------- >>>>> >>>>> The bug and fix were validated using QEMU with a modified CXL configuration. >>>>> >>>>> Two test-only changes were applied (not part of this patch): >>>>> >>>>>    1. QEMU ACPI (hw/acpi/cxl.c): CFMWS restrictions field changed from >>>>>       0x0f to 0x02 (ACPI_CEDT_CFMWS_RESTRICT_HOSTONLYMEM only, without >>>>>       RESTRICT_DEVMEM).  This causes cfmws_to_decoder_flags() to set >>>>>       CXL_DECODER_F_TYPE3 only on the root decoder, simulating a platform >>>>>       that does not permit HDM-DB. >>>>> >>>>>    2. Kernel (drivers/cxl/core/hdm.c): init_hdm_decoder() uncommitted >>>>>       endpoint path changed to force CXL_DECODER_DEVMEM unconditionally, >>>>>       simulating a dual-capable device (supports both HDM-H and HDM-DB). >>>>>       QEMU's cxl-type3 device reports CXL_DEVTYPE_CLASSMEM and defaults >>>>>       to HOSTONLYMEM; this override exercises the DEVMEM commit path that >>>>>       a real Type-2 or dual-capable Type-3 device would trigger. >>>>> >>>>> Bug reproduction (without this patch): >>>>> >>>>>    # cxl create-region -m mem0 -d decoder0.0 -t pmem >>>>>    created 1 region >>>>> >>>>>    HDM-DB committed silently despite CFMWS advertising HDM-H only. >>>>>    No error or warning in dmesg. >>>>> >>>>> Fix validation (with this patch): >>>>> >>>>>    # cxl create-region -m mem0 -d decoder0.0 -t pmem >>>>>    cxl region: cmd_create_region: created 0 regions >>>>> >>>>>    dmesg: >>>>>      cxl_core: cxl region0: mem0:decoder2.0 type mismatch: 2 vs 3 >>>>>      cxl_port endpoint2: failed to attach decoder2.0 to region0: -6 >>>>> >>>>>    The decoder's target_type (2=DEVMEM) mismatches the region's required >>>>>    type (3=HOSTONLYMEM) enforced by the CFMWS restriction -- commit blocked. >>>>> >>>>> QEMU invocation: >>>>> >>>>>    qemu-system-x86_64 \ >>>>>      -kernel bzImage \ >>>>>      -append "root=/dev/sda rw console=ttyS0" \ >>>>>      -drive file=rootfs.img,index=0,media=disk,format=raw \ >>>>>      -M q35,cxl=on -m 4G,maxmem=8G,slots=8 -smp 4 \ >>>>>      -object memory-backend-file,id=cxl-mem1,share=on,mem-path=/tmp/ cxltest.raw,size=256M \ >>>>>      -object memory-backend-file,id=cxl-lsa1,share=on,mem-path=/tmp/ lsa.raw,size=256M \ >>>>>      -device pxb-cxl,bus_nr=12,bus=pcie.0,id=cxl.1 \ >>>>>      -device cxl-rp,port=0,bus=cxl.1,id=root_port13,chassis=0,slot=2 \ >>>>>      -device cxl-type3,bus=root_port13,persistent-memdev=cxl- mem1,lsa=cxl-lsa1,id=cxl-pmem0,sn=0x1 \ >>>>>      -M cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=4G \ >>>>>      -nographic >>>>> >>>>> >>>>> drivers/cxl/core/hdm.c | 29 +++++++++++++++++++++++++++++ >>>>>   1 file changed, 29 insertions(+) >>>>> >>>>> diff --git a/drivers/cxl/core/hdm.c b/drivers/cxl/core/hdm.c >>>>> index 0c80b76a5f9b..127a187cdadb 100644 >>>>> --- a/drivers/cxl/core/hdm.c >>>>> +++ b/drivers/cxl/core/hdm.c >>>>> @@ -802,6 +802,7 @@ static int cxl_decoder_commit(struct cxl_decoder *cxld) >>>>>       struct cxl_port *port = to_cxl_port(cxld->dev.parent); >>>>>       struct cxl_hdm *cxlhdm = dev_get_drvdata(&port->dev); >>>>>       void __iomem *hdm = cxlhdm->regs.hdm_decoder; >>>>> +    struct cxl_root_decoder *cxlrd; >>>>>       int id = cxld->id, rc; >>>>>       if (cxld->flags & CXL_DECODER_F_ENABLE) >>>>> @@ -834,6 +835,34 @@ static int cxl_decoder_commit(struct cxl_decoder *cxld) >>>>>           } >>>>>       } >>>>> +    /* >>>>> +     * Enforce CFMWS memory type policy: reject commits where the decoder >>>>> +     * target_type conflicts with the root decoder's CFMWS restrictions. >>>>> +     * - HDM-DB (DEVMEM) requires CXL_DECODER_F_TYPE2 on the root decoder. >>>>> +     * - HDM-H (HOSTONLYMEM) requires CXL_DECODER_F_TYPE3 on the root decoder. >>>>> +     * - Unknown target_type values leave required_flag zero; skip enforcement. >>>>> +     */ >>>>> +    if (cxld->region) { >>>> >>>> I don't think we should gate the check based on whether cxld->region is valid or not. Can you please take a look at core/ region.c:271:cxl_region_decode_reset() and do something similar to acquire the root decoder by walking up the port hierachy? That should apply the policy check unconditionally. I would also suggest putting this entire block in a helper function. >>> will refer suggested API, and rework upon this. >> Thanks for the pointer -- I looked closely at cxl_region_decode_reset() >> and want to flag something before sending v3, since a literal port-walk >> doesn't fully replace the region lookup here. >> >> cxl_region_decode_reset() doesn't derive the decoder from the port walk >> alone: it's called with cxlr already known, and at each port level uses cxl_rr_load(iter, cxlr) -- keyed by the region -- to find the decoder assigned to that region at that port. The walk finds the *port*; cxlr still finds the *decoder*. >> >> The reason that matters for this check specifically: a single CXL root >> port can host multiple root decoders, one per CFMWS window, each with >> its own restrictions. A pure walk up to is_cxl_root(port) would tell us this decoder's SPA range originates somewhere under that root port, but not *which* of its root decoders' CFMWS restrictions apply -- only the region (or the port's region_ref tracking, which is  also region-keyed) can disambiguate that. >> >> So v3 keeps the region-based lookup (cxld->region->dev.parent -> >> to_cxl_root_decoder()), but addresses what I take to be the actual concern -- silently skipping the policy check -- by making the check itself unconditional instead of gated: >> >> if (dev_WARN_ONCE(&cxld->dev, !cxld->region, >>                        "commit without region assignment\n")) >>             return -ENXIO; >> > > ok sounds good > >> A decoder reaching commit() without a region assigned is now treated as >> a bug (loud WARN + rejected commit) rather than something the check quietly steps around. By the time cxl_decoder_commit() runs, the region assignment has already happened during region assembly (cxl_rr_assign_decoder()), so this should not be reachable in practice. Also pulled the whole block into cxl_decoder_cfmws_check() as suggested. >> >> v3 to follow shortly with this and the F_DEVMEM/F_HOSTONLY rename per >> Davidlohr's BI series. > > Davidlohr seems to indicate that with his code series, this patch may not be needed? I review proposed Davidlohr fixes, and seeing that cxl_region_attach() will prevent this situation. Agree, this patch next version is not needed. Thank you. Regards, Mayank> > DJ > >> >> Thanks, >> Mayank >>>> DJ >>>> >>>>> +        unsigned long required_flag = 0; >>>>> +        const char *type_name; >>>>> + >>>>> +        cxlrd = to_cxl_root_decoder(cxld->region->dev.parent); >>>>> +        if (cxld->target_type == CXL_DECODER_DEVMEM) { >>>>> +            required_flag = CXL_DECODER_F_TYPE2; >>>>> +            type_name = "HDM-DB"; >>>>> +        } else if (cxld->target_type == CXL_DECODER_HOSTONLYMEM) { >>>>> +            required_flag = CXL_DECODER_F_TYPE3; >>>>> +            type_name = "HDM-H"; >>>>> +        } >>>>> + >>>>> +        if (required_flag && !(cxlrd->cxlsd.cxld.flags & required_flag)) { >>>>> +            dev_err(&port->dev, >>>>> +                "%s commit rejected on %s, CFMWS does not permit this memory type\n", >>>>> +                type_name, dev_name(&cxld->dev)); >>>>> +            return -EOPNOTSUPP; >>>>> +        } >>>>> +    } >>>>> + >>>>>       scoped_guard(rwsem_read, &cxl_rwsem.dpa) >>>>>           setup_hw_decoder(cxld, hdm); >>>> >>> Regards, >>> Mayank >>> >> >