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 103EFCDB474 for ; Tue, 17 Oct 2023 05:56:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6739080030; Tue, 17 Oct 2023 01:56:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5FD3C8002D; Tue, 17 Oct 2023 01:56:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4763C80030; Tue, 17 Oct 2023 01:56:59 -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 348968002D for ; Tue, 17 Oct 2023 01:56:59 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id EF333C0ECA for ; Tue, 17 Oct 2023 05:56:58 +0000 (UTC) X-FDA: 81353894916.22.D13BD90 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.126]) by imf29.hostedemail.com (Postfix) with ESMTP id B5A7B120008 for ; Tue, 17 Oct 2023 05:56:56 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=ibOHuG7Z; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf29.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.126 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1697522216; 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=14AddXzDw+P6+ePdNaxRA2p+tMwqUMvBtiPOlup42Yk=; b=dLJwC++NXDnyszvlRAlGu0U/guESCyq2wsGLThITFI6Gkauh//I+3RpJoW9XXK6CEn/M6p O7YkyEcXrpacMnkpdTe48hNidRAN4kZZo4oLmIGmlBJbzLLfbeItYgGjq6WESYfex9484m v02Ba8c6jLJrfl5RuOoD00yAw0/VE2I= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=ibOHuG7Z; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf29.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.126 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697522216; a=rsa-sha256; cv=none; b=Vc9m/iO1nJcgHojTZphsl97S08U8XbCNKC6MamZPKfCp86kZdF9CcvoNjwpKgqyNU9HRgT oTSXGffIj6BBXKlGTqvzIo8Pve7cJtWeQ4fFvH0qWpAM4NFAbiV32dku6qhAxshG6CONJ4 f3ZSi315D7OQUrht7+LkY0UIzVER6vg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697522216; x=1729058216; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=aigizliSGfQOt/MVN5mwaZASQEdSNMmajEsIVyXWVes=; b=ibOHuG7ZFm2DEzVYNnEBNlbXXqKjj3Sh/T+DjPE3JZAal8gzh8tKpbr4 NPuBipOO3lsay9Kdf4XbLyLoYh2ZDqKRphVS43dpMZbdoL3fUeWC11K3k TuwGVPtK0L5Lch87FFORW4vxIEBvvcFPW1jwWCcl9mJYYm06XlJAYpdzA rvmn3/ALEXs7Fx+I1kJGqZFOXbl9D3rZiQRTBrL65vrn/G7rPj35zl/gJ 0x2tKF7UWWAccZ4E+P6i4PODPUjkTwOz18U2pVoJ4jTlKbneBN9IYbZwZ DQ2FuHMG6Q8rlT5SrflSWapA7rtCxWNP0YnIdrnsn/35wj70WRnj9bm5r A==; X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="370775616" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="370775616" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Oct 2023 22:56:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="785370099" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="785370099" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Oct 2023 22:56:51 -0700 From: "Huang, Ying" To: "Verma, Vishal L" Cc: "david@redhat.com" , "Hocko, Michal" , "Jiang, Dave" , "linux-mm@kvack.org" , "osalvador@suse.de" , "aneesh.kumar@linux.ibm.com" , "linux-kernel@vger.kernel.org" , "Williams, Dan J" , "akpm@linux-foundation.org" , "linux-cxl@vger.kernel.org" , "nvdimm@lists.linux.dev" , "dave.hansen@linux.intel.com" , "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: <7a29c85bda2543a0f31d575ced3e57eb93063fc3.camel@intel.com> (Vishal L. Verma's message of "Tue, 17 Oct 2023 13:44:27 +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> <87edhtaksf.fsf@yhuang6-desk2.ccr.corp.intel.com> <7a29c85bda2543a0f31d575ced3e57eb93063fc3.camel@intel.com> Date: Tue, 17 Oct 2023 13:54:50 +0800 Message-ID: <874jip94k5.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: B5A7B120008 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: er7s4bsne17qtfrtxpdori7twgiziebt X-HE-Tag: 1697522216-57634 X-HE-Meta: U2FsdGVkX1/6DVuI+cBYxdtlmmZv3upd7zYXWRaQh46v8GNGTjRglCzZFDvbrsAIVkHDELYNt9ZHJajqXLv+Wu1v1my5hbCw+f/YzZDI/3xv2HT2Pjyfg1u5Ra04nfG43shCwlFGouPGJE/XaTKwppjH4mv2Aa/TiVRbKqKZUM9dW/AczPhvBKIC/ooDbhMhnPHKSVTcMtagJQFMPr+TFEj5KbEyRNtHQgxJ50Dq6oR8bF86xvf7ca2yuwF4gpXRmxNXZRIxrF1O7WZJapNZBzwviqKt2bIlt32TxB5pCF29Ce4A2PrRK3SatBIIHAORA4ENTKiuUfRYWauyWtlWzZ/wnOUUjqkW7HDEqWRRz3xGC6Z5z/3nUPgKINKH1wGnYOGUuHs2JSvk7HENZc2j+wipclXD5BctZtfQsWKuP2qCrPe31lSg2v4EowcxldPn3Zou2xoC49zlBrbGodg8cTSfd49L38hHhNw7T5JWIF7xnPIxn9OEqVyQXncDrmiBc3wn+R6KeTRMwzjqqzFOAtxm0+GoYuTkgRZcr+sWX5oWiMHS9ZaNtrrCvjl4tgfaXUtyruJMQaYT2Z3tCcETYh1wppYvS0eAJ/2BnQiL9CuXiRzBhB88Tm7xU2+u0EPBB+s7FzeLbQC5rxuEcaV0XiWDRdVsI07Txs4aN4nsF8LqLzSn8g3hX5lf2HLd1Gtx7fCUzf6MKq++0P5slHelDNn1L4NTrM3aR4fZ+Ba56F8p/Kgks49Id/tJaTCzhgvB64d53NlStoDkzozvisFO2DVQXcvfcHN8Hs2iwW2MMK7gybwUQW4zn/FBET1wgrgoapxp5YIW1GWBf4UfgNjSgSfPZBqrU9ukFrTKQKYSAEGzuLU0lolnf2Jt4eC6qoj83w4b5rt1Y4ipct3KdZZ3eOQb0cgZXhcv2lqYyzDZlaPSvRqcGutKkDrO3g8OiaATSsxcY82r85k6Gde7I0p 2J9MA+27 td3MUb7EgRnbL+ItAAwoWwCADOTFzaoDDZWl3WElYA2csBFn8Eydt5LUP/RJ8Iv3AAV6v+22fa1TOGk0/ddIPeWW0nm6N/U3vzTUn1k0vCcUpHjzh9MO8TfumASh+0jSckGHHP2lojGpfQa+TyqKrA65fLyBVP6R1ErWdLXTYNSGfKfcml5+eXCAWgWCWCUwsyQFDV5FLHcR8ue5U3x/3Tck2+N3TBNxz2PSo2ViY72W4X1z4HPp6KlMpkaUxRbV7+aZlkR8Gzk8DKPo= 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 Tue, 2023-10-17 at 13:18 +0800, Huang, Ying wrote: >> "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? >> > I think what is happening maybe is while kmem gets detached, the device > goes back to another dax driver (hmem in my tests). So either way, the > check for if (driver) or if (!driver) won't distinguish between kmem > vs. something else. > > Maybe we just remove this check? Or add an explicit kmem check somehow? I think it's good to check kmem explicitly here. -- Best Regards, Huang, Ying