From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C7DDFCDB483 for ; Tue, 17 Oct 2023 05:21:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 413F78D00E8; Tue, 17 Oct 2023 01:21:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3C5078D00DE; Tue, 17 Oct 2023 01:21:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2B2DD8D00E8; Tue, 17 Oct 2023 01:21:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 180128D00DE for ; Tue, 17 Oct 2023 01:21:06 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id E8E6EB61B8 for ; Tue, 17 Oct 2023 05:21:05 +0000 (UTC) X-FDA: 81353804490.09.D375892 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.126]) by imf09.hostedemail.com (Postfix) with ESMTP id DCEAD140017 for ; Tue, 17 Oct 2023 05:21:02 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=lTHY6Llv; spf=pass (imf09.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.126 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1697520064; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=wmo5j5Kddwuva79VAAA3wjzLeRHLPB3smX0BfzNdJTs=; b=MlRR5n2NZNT6XpuzNok0ff3MDNsOEvHHyTpa/vMZkUJ2zVLzaU+OfOVm5qjhxXZjBbnWDK MdkkYFvTssa+2ZMa5mJs5I5hL0zD+dYKY6n/IPpS3aqLn2n/4IGNrEO3KZLlMB5jbk9U3q yQOvNt4+GLheLRiJLP/bI2t7Qb9AnKU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697520064; a=rsa-sha256; cv=none; b=amQNtjujeM9JIuM+8wO+k1OLpn6ADMs2zyeH3SjBXHBGaKDhXk1Hw7b95RJ7UO4cKu9uG9 LosoOwuFSyuxvMfJ5M9VHbX44yY/zQxxKoxy5+5J6AM91WxtXfj8ILqx9Kyv5w95Sb1bhg wu6MzhRlakDoqtYKo0tNPzWvKGsqD3s= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=lTHY6Llv; spf=pass (imf09.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.126 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697520062; x=1729056062; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=0ljYECpynZJuwW/CzHhX9ZRRExV5kXxxKaS9D40UqLM=; b=lTHY6LlvxpIu2ofTU3/5LcoiRXjUnvTWMrQLd8h7HwxUFcRGa402nuk0 y0CivI755Z/+xXaAp+ObIV7VIB9yj1L5ZF4YVBvqRphrpBGX5dBK0jFkj Y4r8qmIukxDxJxFM49ambUD1YGOVML1vh1VGEiVP5PNOwH0bF8Q9erxV1 sJT96hpZ70ULLiEFvzBR9nvJq/9+KLn7tM7WLWMe6tlQWpM9quncR1Bkl cFcdV85y0FIUfGKdnjtbbOaeBJhZJeGkpOe0wF9sbaz2zMlhkP8T6I8VT cB8lRt0e4y7FvhJAl3vqfxUZ3QJf1Yq3TAfh2XbE2lVTdIbJeiUNyJQum Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="370771755" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="370771755" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Oct 2023 22:21:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="846685324" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="846685324" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Oct 2023 22:20:56 -0700 From: "Huang, Ying" To: "Verma, Vishal L" Cc: "Williams, Dan J" , "Jiang, Dave" , "osalvador@suse.de" , "david@redhat.com" , "akpm@linux-foundation.org" , "dave.hansen@linux.intel.com" , "linux-mm@kvack.org" , "aneesh.kumar@linux.ibm.com" , "linux-kernel@vger.kernel.org" , "linux-cxl@vger.kernel.org" , "Hocko, Michal" , "nvdimm@lists.linux.dev" , "jmoyer@redhat.com" , "Jonathan.Cameron@huawei.com" Subject: Re: [PATCH v5 2/2] dax/kmem: allow kmem to add memory with memmap_on_memory In-Reply-To: <923d65270ad08d47adae0d82ab4b508d01e9cc00.camel@intel.com> (Vishal L. Verma's message of "Tue, 17 Oct 2023 08:31:04 +0800") References: <20231005-vv-kmem_memmap-v5-0-a54d1981f0a3@intel.com> <20231005-vv-kmem_memmap-v5-2-a54d1981f0a3@intel.com> <651f27b728fef_ae7e7294b3@dwillia2-xfh.jf.intel.com.notmuch> <923d65270ad08d47adae0d82ab4b508d01e9cc00.camel@intel.com> Date: Tue, 17 Oct 2023 13:18:56 +0800 Message-ID: <87edhtaksf.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-Rspamd-Queue-Id: DCEAD140017 X-Rspam-User: X-Stat-Signature: 9xipwmb7i3uyi5zstq8g8gbw8fgik4j1 X-Rspamd-Server: rspam03 X-HE-Tag: 1697520062-133955 X-HE-Meta: U2FsdGVkX18dYOJ0bSmnqh3HUYqqwSmhBvE24qWtB62BLcS24NuT1Wy8OPVXKJWC1BpNPeNT87XDYO54ED3+TC7KZ/HJNslDFJxVOIt+ypv0BgzL4zqzlCGkHn4J77LfB5wo8LyhVFa34kcUljXPlDhg8GNVAAIAimBzr9TR32zccv1cqIRDnd1IIwjS3lvJjiFv4icPB/dVtfWBLIT8b4NPJVr/r+4gbyyIBMKJ7gdX8zoIZdcxB3w4FqB4rcjHbFMdvLOH9ThImHxZklyQbN2IfvzOF4kvkIRlYsO3841FYcwGAsaC4SVGXWA0UqE+G26vI61yRDnYxaIB0Duu8s0Bwp5jJppn/oSEBLpEHnWEqT0WFmKuo98DOslQYZxIc4IT9G6oQlElP96iWR+/yFWPjiOQz4JNqc9NlbBiSSIgEC+6WqZlzwPAIFHlx42wYywPJ9+73lCei2OD8xsKW3OKtIW/QlVTAZA74X9yzLzbvhJb9nlHPP1POOH+6J07hH/+gfbSz8WWD18ivK2U9XF4Su2M0oEutqAYbjGTDiNgWB7w92yselvxZvbesxZiHCUFms/FUGHf/YlfG37bjothiMMMGFF7ORHRMK5l8myhMWfFQME3NfNnrFE+G/SS9VbLfJxdb0/3nYsJXTTSLTPp8JbfcquhBX/Sj/caYZ984ew1zzeURLf58DZsNj8d3CWLEDL6APMRVoMw2yNroITfULZOq+7cNwJ6xZY+S2X0duZYZWNo71yuFXKyHVAZKkm3VuPqO9AJP2xzYFy/YuWDRYgRhKEq549dBVKmVfynzBNSBeUO7+aUTQ07GeryfV/kv+YTqWwAgjOHEk929pwz49RWWmSUaPAXcTfdy+Y1SpMcTGubOK9OEFCggDtf0l4Ss1+8rPzjD+EevWfHy54HzmTdCVKc9+C9oOxoC7KEAPDC5IN2YWYFTUNeusGgZS3SPc7mcXZbAqdTNIM m74NyCD5 2xzaQzgy6Z4IZ/0wSTbpa96LMoh4xmRkD3Bfhn/fgCioAPlFI8LnX+lMzYZAbdwsh+H7ze1R3PP+G5HJi3oUT6hQlkRgvfqQiG99vnJUXrA3+UupAnXO45z5vNqKlWkD6bxHbEG4kUWD3hUVQ+ixA97wG2Lud0703foY2KkdHHHQ+ohQuCU4E4Lzr6UDad38Au3BuA6zTJDfBv3YGNBdXfAlI3g+NMnlfOFVSSZoCgldlz7eueXvPWE4o2qepEGa0t1plGsR3MA9jayU= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: "Verma, Vishal L" writes: > On Thu, 2023-10-05 at 14:16 -0700, Dan Williams wrote: >> Vishal Verma wrote: >> > > <..> > >> > + >> > + rc = kstrtobool(buf, &val); >> > + if (rc) >> > + return rc; >> >> Perhaps: >> >> if (dev_dax->memmap_on_memory == val) >> return len; >> >> ...and skip the check below when it is going to be a nop >> >> > + >> > + device_lock(dax_region->dev); >> > + if (!dax_region->dev->driver) { >> >> Is the polarity backwards here? I.e. if the device is already attached to >> the kmem driver it is too late to modify memmap_on_memory policy. > > Hm this sounded logical until I tried it. After a reconfigure-device to > devdax (i.e. detach kmem), I get the -EBUSY if I invert this check. Can you try to unbind the device via sysfs by hand and retry? -- Best Regards, Huang, Ying >> >> > + device_unlock(dax_region->dev); >> > + return -ENXIO; >> [snip]