Received: by 2002:a05:7412:8d10:b0:f3:1519:9f41 with SMTP id bj16csp4339609rdb; Mon, 11 Dec 2023 16:58:57 -0800 (PST) X-Google-Smtp-Source: AGHT+IGWV+GlIlCVmmYAjeGFPyApTpP2befmlYrsisZCJEVeKr4tcBc5EsqfN6SdXVcGTGmeGdpH X-Received: by 2002:a05:6a20:8921:b0:190:2f4f:de80 with SMTP id i33-20020a056a20892100b001902f4fde80mr6060294pzg.50.1702342736731; Mon, 11 Dec 2023 16:58:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702342736; cv=none; d=google.com; s=arc-20160816; b=Br3EAbV+SdomXv2byR9XWEBXfgSEc9esTu2yeWfFrjQHj9CI6CfBq5yFX2AjQmXimy 2ncqpwhHvnSejPCi/O8Kp8TzjkJ6dNMaetJCa5x9UG6MvpADmFN4Pd/Hj+E1nas0hZSj CdjkwiGTSqxJl3m0qSpgiq/dYcIWIcW+Fg0bAQRRTD7tnaJq2AibvpgXUVNpA5pfgNOy 8LwVMCBFzcCZWwwWy45z0XrTzxMp9vqPTKpnJu8uj8QI634XFWzh+dhHfyYvNwlUe456 kGJEEmMvgY09uz0sYTgoK7agmCr883V55A/TqSzA/y+42JhgDFHJzy2g10wuPdrUkp2N uLOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:dkim-signature; bh=EY7OnWNG+WCNSUT/D7uG1g2mEfQiA1WOjjO8kRcLawQ=; fh=bAurRUbqSalwe4L4JYO58eUeyg+5BNkop/UBmRkBgfM=; b=PL714ElyqvoxvGYdlqgZFu/0fjohUKQ0l6uVtJbE2Z0S2IdXfli/FqokuHWcom9J42 podQQgcpVkjCG7f4+ym8feFH+0ygM5ZYx/8nMdpAzzKAQ9JxiInAGJrOAStboquVQ4fQ VmT5JBStS0Elw6SiqPUQw686Wtugb+qCtFJ4flefQqlidTdZN45g/BeFcAAS0M83Ul0k MHqSS13ch9TATuyrMb8KYTXMCxehM04w8aXbz62nlnKRDSpUUY4b4A71nK4bz08XYkNp ZqTg+dKVg4E4tWysHAgotmYRZcP0BXB3p61QWPjusBVyDMylG9s52zwnTNBuQbd7RkcK VhOg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=UACTZqHu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from howler.vger.email (howler.vger.email. [2620:137:e000::3:4]) by mx.google.com with ESMTPS id z2-20020a63c042000000b005c69bfad79fsi6780786pgi.77.2023.12.11.16.58.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Dec 2023 16:58:56 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=UACTZqHu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id C973F8047652; Mon, 11 Dec 2023 16:58:53 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345607AbjLLA6c (ORCPT + 99 others); Mon, 11 Dec 2023 19:58:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54352 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345632AbjLLA6a (ORCPT ); Mon, 11 Dec 2023 19:58:30 -0500 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A182BC3; Mon, 11 Dec 2023 16:58:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1702342716; x=1733878716; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=nso73b76ltEzpEq8N8M/qI8Y1oyBdGdHXb+w/8UiECk=; b=UACTZqHuR+hGL16AYDmvJ9oUqyVUsZt6u57FSQMriFSjKt5cRYmWT9wT e9H45iFYQ9uWLTl6E2lvENkUYFEYD7B1oUn1+0EgKA0r2JDyDEq+Lbm/B qtV6FXgqNjiVvnljxvMeOkp+IrKxQVE+URYninmOpX/GVxordSpFYZk/b xqTBrkY3cdu64QU50AtWSkVph0v+xOU5ke4gDiMAi8Lty0svgtHPxH0jU EkVOXcF/Y44xms4xP/9jdbW//DH040U1cjUQ4hPRPEVlDEYLJVfELvOHu eYjMZa5MvC4FSuyJAb98bKrXGfpajiLSJggW9SqZnQFONvSNr9jfNrDDf w==; X-IronPort-AV: E=McAfee;i="6600,9927,10921"; a="459046254" X-IronPort-AV: E=Sophos;i="6.04,269,1695711600"; d="scan'208";a="459046254" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Dec 2023 16:58:36 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10921"; a="843711895" X-IronPort-AV: E=Sophos;i="6.04,269,1695711600"; d="scan'208";a="843711895" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Dec 2023 16:58:33 -0800 From: "Huang, Ying" To: "Verma, Vishal L" Cc: "david@redhat.com" , "Jiang, Dave" , "dave.hansen@linux.intel.com" , "linux-cxl@vger.kernel.org" , "Jonathan.Cameron@huawei.com" , "linux-kernel@vger.kernel.org" , "Williams, Dan J" , "nvdimm@lists.linux.dev" , "lizhijian@fujitsu.com" Subject: Re: [PATCH v3 2/2] dax: add a sysfs knob to control memmap_on_memory behavior In-Reply-To: (Vishal L. Verma's message of "Tue, 12 Dec 2023 08:40:57 +0800") References: <20231211-vv-dax_abi-v3-0-acf6cc1bde9f@intel.com> <20231211-vv-dax_abi-v3-2-acf6cc1bde9f@intel.com> <87msugxnx9.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Tue, 12 Dec 2023 08:56:33 +0800 Message-ID: <87il54xmpq.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on howler.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Mon, 11 Dec 2023 16:58:54 -0800 (PST) "Verma, Vishal L" writes: > On Tue, 2023-12-12 at 08:30 +0800, Huang, Ying wrote: >> Vishal Verma writes: >> >> > Add a sysfs knob for dax devices to control the memmap_on_memory setting >> > if the dax device were to be hotplugged as system memory. >> > >> > The default memmap_on_memory setting for dax devices originating via >> > pmem or hmem is set to 'false' - i.e. no memmap_on_memory semantics, to >> > preserve legacy behavior. For dax devices via CXL, the default is on. >> > The sysfs control allows the administrator to override the above >> > defaults if needed. >> > >> > Cc: David Hildenbrand >> > Cc: Dan Williams >> > Cc: Dave Jiang >> > Cc: Dave Hansen >> > Cc: Huang Ying >> > Tested-by: Li Zhijian >> > Reviewed-by: Jonathan Cameron >> > Reviewed-by: David Hildenbrand >> > Signed-off-by: Vishal Verma >> > --- >> > drivers/dax/bus.c | 47 +++++++++++++++++++++++++++++++++ >> > Documentation/ABI/testing/sysfs-bus-dax | 17 ++++++++++++ >> > 2 files changed, 64 insertions(+) >> > >> > diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c >> > index 1ff1ab5fa105..2871e5188f0d 100644 >> > --- a/drivers/dax/bus.c >> > +++ b/drivers/dax/bus.c >> > @@ -1270,6 +1270,52 @@ static ssize_t numa_node_show(struct device *dev, >> > } >> > static DEVICE_ATTR_RO(numa_node); >> > >> > +static ssize_t memmap_on_memory_show(struct device *dev, >> > + struct device_attribute *attr, char *buf) >> > +{ >> > + struct dev_dax *dev_dax = to_dev_dax(dev); >> > + >> > + return sprintf(buf, "%d\n", dev_dax->memmap_on_memory); >> > +} >> > + >> > +static ssize_t memmap_on_memory_store(struct device *dev, >> > + struct device_attribute *attr, >> > + const char *buf, size_t len) >> > +{ >> > + struct device_driver *drv = dev->driver; >> > + struct dev_dax *dev_dax = to_dev_dax(dev); >> > + struct dax_region *dax_region = dev_dax->region; >> > + struct dax_device_driver *dax_drv = to_dax_drv(drv); >> > + ssize_t rc; >> > + bool val; >> > + >> > + rc = kstrtobool(buf, &val); >> > + if (rc) >> > + return rc; >> > + >> > + if (dev_dax->memmap_on_memory == val) >> > + return len; >> > + >> > + device_lock(dax_region->dev); >> > + if (!dax_region->dev->driver) { >> > + device_unlock(dax_region->dev); >> > + return -ENXIO; >> > + } >> >> I think that it should be OK to write to "memmap_on_memory" if no driver >> is bound to the device. We just need to avoid to write to it when kmem >> driver is bound. > > Oh this is just a check on the region driver, not for a dax driver > being bound to the device. It's the same as what things like > align_store(), size_store() etc. do for dax device reconfiguration. Sorry, I misunderstood it. > That said, it might be okay to remove this check, as this operation > doesn't change any attributes of the dax region (the other interfaces I > mentioned above can affect regions, so we want to lock the region > device). If removing the check, we'd drop the region lock acquisition > as well. This sounds good to me. And is it necessary to check driver type with device_lock()? Can driver be changed between checking and lock? -- Best Regards, Huang, Ying