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 E46B9CD343E for ; Tue, 19 Sep 2023 05:58:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 670E16B04A4; Tue, 19 Sep 2023 01:58:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 621306B04A6; Tue, 19 Sep 2023 01:58:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 511096B04A7; Tue, 19 Sep 2023 01:58:51 -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 4340E6B04A4 for ; Tue, 19 Sep 2023 01:58:51 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 169691A09E8 for ; Tue, 19 Sep 2023 05:58:51 +0000 (UTC) X-FDA: 81252293262.09.943D3E6 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.115]) by imf03.hostedemail.com (Postfix) with ESMTP id 7F77A20003 for ; Tue, 19 Sep 2023 05:58:48 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=LCkOYWYs; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf03.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.115 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=1695103129; 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=zAXNnjHQ3dO7Ak24DeY9zXAdYe19wsgH8Qj7L850Bo8=; b=c5WaFiR724HZVcSTNE37sJ7Vx8alnoH3jlMwlFe35BrBuBVVJvwBsG0a0qjEKF5FqZz9uP 9QKKEIEIIkFSMJqYn3Vx1MB6rVNNhxWM8rLlceDwwfQFNPFR3PLSss22e3S1QtcvRlTMz3 LVZkaEVw8JEBe2/KH8jrA87nUmtuTq4= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=LCkOYWYs; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf03.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.115 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695103129; a=rsa-sha256; cv=none; b=O+41ZplOGlOWNN2BuysX/MufF/7OEaoA6W4h1bJkHmA7QYa8ChxDflElocUkmIkZvGXR0J YMNZobLOggMZHuer+hO/neoGOVuj+X0XpFr8KMxVflmTOZvMz7zE7tPL7FnJm3G+78e1QO vB6UUJdfbCNCabeMkyrdLWSDBZ1hra0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695103128; x=1726639128; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=KAmPPpxW9liLl58sEZSznsJl5MqLZx/QqZBmppsxNqU=; b=LCkOYWYst/bxzFBke65kgRzkPK2RYKRybeCIbssVo7DtOT3VMGi842Do A5gc9VWstukiwkw+CjiPHur1JjlT/GxbqvTa5myh5uWo3Bpoc9RMqRPbC GVHb8p0FwJKRxLw/Pf8t1joNatp4eiJtUv97nxkc8+sGDYa1l3uXSrWr+ fe+9QvJ2dJ27bbmIAZpANMqL6zEzpt9LnrFLLxa96kRbIsnwEKlEfEzkA CcRPE3bZTZsGa/0zF7GPAH6UdyRzixo1L6S0jAntZqADzO1w16FROoskQ dJAK+EGnx/nZ0p33jxVjSNRFbEwIEkqE9zhNPLf9KS3N9z+J9wqgE71Es A==; X-IronPort-AV: E=McAfee;i="6600,9927,10837"; a="379761896" X-IronPort-AV: E=Sophos;i="6.02,158,1688454000"; d="scan'208";a="379761896" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Sep 2023 22:58:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10837"; a="919737430" X-IronPort-AV: E=Sophos;i="6.02,158,1688454000"; d="scan'208";a="919737430" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Sep 2023 22:58:41 -0700 From: "Huang, Ying" To: Alistair Popple Cc: Andrew Morton , , , Bharata B Rao , "Aneesh Kumar K . V" , Wei Xu , "Dan Williams" , Dave Hansen , Davidlohr Bueso , Johannes Weiner , Jonathan Cameron , Michal Hocko , Yang Shi , Dave Jiang , Rafael J Wysocki Subject: Re: [PATCH -V3 4/4] dax, kmem: calculate abstract distance with general interface References: <20230912082101.342002-1-ying.huang@intel.com> <20230912082101.342002-5-ying.huang@intel.com> <87y1h24tft.fsf@nvdebian.thelocal> Date: Tue, 19 Sep 2023 13:56:33 +0800 In-Reply-To: <87y1h24tft.fsf@nvdebian.thelocal> (Alistair Popple's message of "Tue, 19 Sep 2023 15:31:29 +1000") Message-ID: <8734zayacu.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspam-User: X-Stat-Signature: i1nzfonskcsktd7cimweudiaxcjx9i5t X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 7F77A20003 X-HE-Tag: 1695103128-129099 X-HE-Meta: U2FsdGVkX1/g0fYp3SHTU2Yna8hUbFDOfCertSPKNQMS8fqWqukQBdXoyN/k7Me9ZyJE0MT2dxFMVEMIXwv7mNTrjQDaYpaT51zUUM9I+Z3pE63XckidOCqs1o5Ip1/oOljfu362+k3cEyzUCl/EtytVzT/m7DzYm1Z7keNJdmyHG73rk9tQwb8ytTK9vy1NwzFjW7FfY0cSR/ijZxLx82dcBk7lgfbnZ9GBCeKhtv0s1IvqdULwTXIlEnhKi8gD7qv8LGMQAjLeiQmVCKj0fH9VW4A1UG9icyTuBqNkGHdbMEnssPuSbRJoxZ8BjeOtZXODzgfukegH6rtYot4TVmKx29dL2/yFpwNxenHEmPAYLt8oxPLF2W7eERnEruzqAB8gtjfjB41bOZhGW6GzXgZ/kT2thY7vz5i3DywkNJzyAFcpKlzKQ64Pwao3stip9omg4lySUhzs1ZF7w7hec79jM1b5BGhC7uDtqDBXE37ViTTyXstgk/tJFPNALrR6s3ZDVTOJuRbBTJvM9CyCW8BIeXUr4aHttsZ2FQVEUQpBcF2VE20v4TLXYKGyBdRmc9Cggu0k2Q8/3Lo24dNOY+okD6FQOWuDUuo7cd6Ue6wV7iHmpxlV4H+CAo3tyRpGvqmnwuhlbPnOJ8GvcMGQsa0sRgB3K2ZMkG01T0wz2eBculYVBWeu2nUG8RDKa87n2EC5huAM6HxyNis290PBNy1yMhYxu+GWu/sV34Nxdlkir+VHx5zsIedT7DjNV6KEqviYISSBVD3m4H/5y2+hsDq+NFp3UkotoCIZz7RlLoEDaEgylWtXVP+EL0BLrud//JTTzfL+9yuqEr22NSiF4vIG3NYulV9A/iA1YIGfj3DMHUWNkcLcu25ExS4GhDrpBsTk9WF0XHOM5Zys8rl5rnX12URVijDzw7FcpewaBujP3wX2jDVQzGz1NWEsOn5AC8I2PQ7qxLA9wfO1Yp1 suYD53WO 1qurbfcGX/pZ8UAYQqELBZ2hbCFW1XEoq3VwC5Z53P1yg3Ex/l/yJUHm6ysevV0dgaRVN82/iDyNIvK06M3o1tfx8IADYuLSis3aE9U3OjaIXf8s58uBC+pfLri9+n2K69YBeDK0gSbf+Py4jm2Qn/0v/ZTuPQFEhAHJAqkoIl8eBH1IryH9A9WSaYLIviPKTdxEPPVCLEdTKcG39xIO0onb4Ag== 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: Alistair Popple writes: > Huang Ying writes: > >> diff --git a/mm/memory-tiers.c b/mm/memory-tiers.c >> index fa1a8b418f9a..ca68ef17554b 100644 >> --- a/mm/memory-tiers.c >> +++ b/mm/memory-tiers.c >> @@ -586,7 +586,7 @@ EXPORT_SYMBOL_GPL(init_node_memory_type); >> void clear_node_memory_type(int node, struct memory_dev_type *memtype) >> { >> mutex_lock(&memory_tier_lock); >> - if (node_memory_types[node].memtype == memtype) >> + if (node_memory_types[node].memtype == memtype || !memtype) >> node_memory_types[node].map_count--; >> >> /* >> * If we umapped all the attached devices to this node, > > This implies it's possible memtype == NULL. Yet we have this: > > * clear the node memory type. > */ > if (!node_memory_types[node].map_count) { > node_memory_types[node].memtype = NULL; > put_memory_type(memtype); > } > > It's not safe to call put_memory_type(NULL), so what condition guarantees > map_count > 1 when called with memtype == NULL? Thanks. Nothing guarantees that. Thanks for pointing this out. I will revise the code to put_memory_type(node_memory_types[node].memtype) firstly. -- Best Regards, Huang, Ying