Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp4377033pxu; Wed, 9 Dec 2020 15:55:37 -0800 (PST) X-Google-Smtp-Source: ABdhPJxUTSoebz/ktW6vbAJmg8TYzCa6VFl6/5fZfjjhpcBNo5ecteLfNZkDgyDpK8g6knSk410d X-Received: by 2002:a17:906:7f10:: with SMTP id d16mr4118342ejr.104.1607558137258; Wed, 09 Dec 2020 15:55:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607558137; cv=none; d=google.com; s=arc-20160816; b=kv4mL1VjUhcJ6Cunf9ju0N1NaU30LARNAChrHXP9VhQA1zuLH7Z7vlmqO+OjZLJLdi i8qzpBhlbJ7JuQX6MJ0crScg2KLvTJXckpIOQD1Q5xIEvw35MWkBNjus4d66gDdyjKQF 8XgnkZry6bA1msCNsKFjm9ZhwhDuLyd3nLl0qVFRYcPwCcQN27U4+6lXOuYDMgyqoZ25 jsZgj77KI4U07cXSPg3XpeHSEKLI/JZj/ffyi4IM2rEAKnfBl/8w3q6HDpuhcXCGKaPi 9ZY4UkmQu+4uU8SDXm2ds4BavRBinUOyvK0R7LDi6bsnmkLZZKaPoniGCtKrs6Dm8W9Y 0ULg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=pIQL03/zPKLYNtedDsrbaZi2weGw3ezzccqUR9STUu4=; b=P/2RDr3QUIZF0u6O3ng+ZfTKYEsQvjCGPl0/WeKyV18bQUIrb26Nnq7IjiFclsbqcS pXLtdl6Mjt0IBme8ttC4Hfe5afVCDerzZwIC0y81s0OvYtgbfyUxKDAcTloPApEOaVnx z+fGlJVOGjC05RkfiW4pfQtuRyssBr6qcvmsy1rfMeB07nOvtikveRSBnBrdyXH2VZmO VxNaNEvsrqdHlQwteCUSjrWU5JnK5nBtB8V7RJ3Q7+I9cKrPjccmmw6TAgMDjkL/uR4/ 5Wq0Aa/QfCMtY8HEptIC2xAkQdBzwrKbasfnhkyE6SZ/Rc/h7FemXhekxzEOxkdqPeOs 7p2w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b="l2Ft/LcF"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p20si1576328ejw.65.2020.12.09.15.55.15; Wed, 09 Dec 2020 15:55:37 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b="l2Ft/LcF"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389045AbgLIWju (ORCPT + 99 others); Wed, 9 Dec 2020 17:39:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55734 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388716AbgLIWje (ORCPT ); Wed, 9 Dec 2020 17:39:34 -0500 Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 486A9C061794 for ; Wed, 9 Dec 2020 14:38:53 -0800 (PST) Received: by mail-ed1-x544.google.com with SMTP id q16so3369142edv.10 for ; Wed, 09 Dec 2020 14:38:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pIQL03/zPKLYNtedDsrbaZi2weGw3ezzccqUR9STUu4=; b=l2Ft/LcFTKYXO8IPePZ2BYv+uOHAjdrRbZntfnElLBHe0ZXC/kvJFcPyKVcvQ7D6OC Ue0zE1ERVHPYKqttcjjlWhTf2s0uaI5dGJX558cBCfmdBjJ1YhR2q9I4hcqFMIhCBYy3 f92ybU4JscstvCIPyOrP6FDwNOMpHmExMR79vy/Pj4pPSKHqUT3P0bs8gtHYCzBIqPXn Fy4Z9nV18PfB+jKufBdaYSEikISgiHZEhse+SqEI80SzefwRNMqhuD6qnXj77wM3zLRv x0eFWyAqda4DUVZB8Kibs4DJcmJymY00M84nFgWTcUnME/v7ZzJHl5gekjJF+o7j1PCB TvVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pIQL03/zPKLYNtedDsrbaZi2weGw3ezzccqUR9STUu4=; b=aJ2qxJZ9ihHnovkTrCy+TsTgewsEAfAZWv4czCo9WzHiGIpOHIiQlm5oWDuKyrbjRa YiiSbRuGPRu6T0w7iirNS1UL5FwYoayFREU6izLsP7dK8wu0J7rFJaiTy3aHqTCRgagN 45eThaITn3fKnflXdzh5v1emHqnTN6FpULrNPA+51HC1zUwtFuKahrW4jcP2WNJZHlOM 8pUnQmwJKwAy9QQ+igWkFS95+6z/BgsAZRljRJaWXzOmSM48OAkmGEy7gDF/BM/Ip+s5 2s0zIqfPSDbPmWeUDSe7pew99So49Vji9E/fsyKSOTOfmZvgFi/RRE5cts/2iK3XZ1+a elSQ== X-Gm-Message-State: AOAM532JwYlQ95l6HnGTGW2DxZtOBNzDFhwsEddE3FGjcLLeF5Yw3f7h ggDh6vNBW2JM+vF5DhHtD/pLYnBajPPKGsJTM7koBw== X-Received: by 2002:aa7:cdc3:: with SMTP id h3mr4022893edw.52.1607553531849; Wed, 09 Dec 2020 14:38:51 -0800 (PST) MIME-Version: 1.0 References: <20201209002418.1976362-1-ben.widawsky@intel.com> <20201209002418.1976362-12-ben.widawsky@intel.com> In-Reply-To: <20201209002418.1976362-12-ben.widawsky@intel.com> From: Dan Williams Date: Wed, 9 Dec 2020 14:38:49 -0800 Message-ID: Subject: Re: [RFC PATCH 11/14] cxl/mem: Add a "RAW" send command To: Ben Widawsky Cc: linux-cxl@vger.kernel.org, Linux Kernel Mailing List , Linux PCI , Linux ACPI , Ira Weiny , Vishal Verma , "Kelley, Sean V" , Rafael Wysocki , Bjorn Helgaas , Jonathan Cameron , Jon Masters , Chris Browy , Randy Dunlap , Christoph Hellwig Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 8, 2020 at 4:24 PM Ben Widawsky wrote: > > The CXL memory device send interface will have a number of supported > commands. The raw command is not such a command. Raw commands allow > userspace to send a specified opcode to the underlying hardware and > bypass all driver checks on the command. This is useful for a couple of > usecases, mainly: > 1. Undocumented vendor specific hardware commands > 2. Prototyping new hardware commands not yet supported by the driver > > While this all sounds very powerful it comes with a couple of caveats: > 1. Bug reports using raw commands will not get the same level of > attention as bug reports using supported commands (via taint). > 2. Supported commands will be rejected by the RAW command. > > Signed-off-by: Ben Widawsky > --- > drivers/cxl/mem.c | 32 ++++++++++++++++++++++++++++++++ > include/uapi/linux/cxl_mem.h | 14 ++++++++++++-- > 2 files changed, 44 insertions(+), 2 deletions(-) > > diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c > index 0bf03afc0c80..a2cea7ac7cc6 100644 > --- a/drivers/cxl/mem.c > +++ b/drivers/cxl/mem.c > @@ -115,6 +115,7 @@ struct cxl_mem_command { > > static struct cxl_mem_command mem_commands[] = { > CXL_CMD(INVALID, NONE, 0, 0, "Reserved", false, 0), > + CXL_CMD(RAW, TAINT, ~0, ~0, "Raw", true, 0), Why is the taint indication in the ABI? It seems like it only needs to be documented. > }; > > static int cxl_mem_wait_for_doorbell(struct cxl_mem *cxlm) > @@ -326,6 +327,20 @@ static int cxl_mem_count_commands(void) > return n; > }; > > +static struct cxl_mem_command *cxl_mem_find_command(u16 opcode) > +{ > + int i; > + > + for (i = 0; i < ARRAY_SIZE(mem_commands); i++) { > + struct cxl_mem_command *c = &mem_commands[i]; > + > + if (c->opcode == opcode) > + return c; > + } > + > + return NULL; > +}; > + > /** > * handle_mailbox_cmd_from_user() - Dispatch a mailbox command. > * @cxlmd: The CXL memory device to communicate with. > @@ -421,6 +436,23 @@ static int cxl_validate_cmd_from_user(struct cxl_send_command __user *user_cmd, > c = &mem_commands[cmd.id]; > info = &c->info; > > + /* Checks are bypassed for raw commands but along comes the taint! */ > + if (cmd.id == CXL_MEM_COMMAND_ID_RAW) { > + struct cxl_mem_command temp = > + CXL_CMD(RAW, NONE, cmd.size_in, cmd.size_out, "Raw", > + true, cmd.raw.opcode); Oh, I thought CXL_CMD() was only used to populate the mem_commands array. Feels out of place to use it here when all it is doing is updating the size_{in,out} and opcode fields. Mainly I'm interested in CXL_CMD() enforcing that the command-id is the mem_commands index. > + > + if (cmd.raw.rsvd) > + return -EINVAL; > + > + if (cxl_mem_find_command(cmd.raw.opcode)) > + return -EPERM; > + > + add_taint(TAINT_WARN, LOCKDEP_STILL_OK); TAINT_WARN seems the wrong value, especially since no WARN has occurred. I feel that this is more in the spirit of TAINT_PROPRIETARY_MODULE, TAINT_OVERRIDDEN_ACPI_TABLE, and TAINT_OOT_MODULE. How about a new TAINT_RAW_PASSTHROUGH? I could use this for the acpi/nfit driver as well to disclaim responsibility for system errors that can result from not using the nominal kernel-provided commands.