From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B390D38F23F for ; Mon, 22 Jun 2026 08:13:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782116021; cv=none; b=s3waVjrQRiOue4mARF23r+XLIBwMTTrMBssI530zUmZfh03s0xexE/4Vk1DUiefJFulctDPo6l7wvGIt5xntYK6nJzQjPMMzWHF7RUsn5wEN6xA+N0pjU3hi/3Utp99lNZokkLzRqaVQyu8qN6a5eP40fYZd2HangPeLSeKIg5I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782116021; c=relaxed/simple; bh=55pYdM/0X/gY7lsijQt+lVoe4ZgRE5hiLdnxN1F1wys=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=FjZCVXegjOXzU9SDY7OEHEaQGc7FjKaw0jl67Oc2yOx1YWgosk4iz/QCbVk2FyNBtjYgdPhZUkCBbcf5pnJmiDnpgvOg7s2TOMvqySGTwjxkCDvtkPTBHHAvnhJAUa8eVo181FVL8pGIEwhC+4lyh0u9ZWHpbghpSQaPnXx5jH0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=PAbsdqpT; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="PAbsdqpT" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EE1EF1BF7; Mon, 22 Jun 2026 01:13:31 -0700 (PDT) Received: from [10.164.19.14] (unknown [10.164.19.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DAFDF3F632; Mon, 22 Jun 2026 01:13:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1782116016; bh=55pYdM/0X/gY7lsijQt+lVoe4ZgRE5hiLdnxN1F1wys=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=PAbsdqpTB9bBmH0OMrY/a9PGPUK6A3B5TLXnGG0jgDqAkY6ctLnmLSRI9+6X732wt GV61Tf8sdHrfejsc1aMB0ghFAc12sPu6Vr3u35ja85/Uhwu7zrFudU2fvLA6M1PkvW QiPTzzKlqIsOpUUZQp/gqLz8D/nRCfocKCWrlF38= Message-ID: Date: Mon, 22 Jun 2026 13:43:26 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 02/12] mm/rmap: Add try_to_unmap_hugetlb_one To: Lance Yang , "David Hildenbrand (Arm)" Cc: akpm@linux-foundation.org, ljs@kernel.org, chrisl@kernel.org, kasong@tencent.com, hughd@google.com, liam@infradead.org, riel@surriel.com, vbabka@kernel.org, harry@kernel.org, jannh@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, qi.zheng@linux.dev, shakeel.butt@linux.dev, baohua@kernel.org, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, shikemeng@huaweicloud.com, nphamcs@gmail.com, bhe@redhat.com, youngjun.park@lge.com, baolin.wang@linux.alibaba.com, pfalcato@suse.de, ryan.roberts@arm.com, anshuman.khandual@arm.com References: <20260618074449.24974-1-lance.yang@linux.dev> <0fe2a584-c633-4f82-8c47-d204e3b39a57@linux.dev> <22613c23-612b-4de0-8731-00ad2da63eae@linux.dev> Content-Language: en-US From: Dev Jain In-Reply-To: <22613c23-612b-4de0-8731-00ad2da63eae@linux.dev> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 18/06/26 3:31 pm, Lance Yang wrote: > > > On 2026/6/18 17:43, David Hildenbrand (Arm) wrote: >> On 6/18/26 11:09, Lance Yang wrote: >>> >>> >>> On 2026/6/18 15:55, David Hildenbrand (Arm) wrote: >>>>>      return __rste_to_pte(pte_val(*ptep)); >>>>> } >>>>> >>>>> >>>>> So plain ptep_get() can feed raw huge-entry bits into pte_pfn(), and the >>>>> derived subpage can be wrong. >>>> >>>> Good question which impact that might have in practice? >>> >>> The subpage check can warn, but we still pass that subpage to >>> make_hwpoison_entry(). So the hwpoison marker can end up with the >>> wrong PFN? >>> >>> +    subpage = folio_page(folio, pte_pfn(pteval) - folio_pfn(folio)); >>> +    VM_WARN_ON(folio_page(folio, 0) != subpage); >>> [...] >>> +    pteval = swp_entry_to_pte(make_hwpoison_entry(subpage)); >> >> My s390x page table knowledge is a bit rusty. >> >> IIUC, it would be a problem if some PTE bits in segment/region entries (pmd/pud/ >> ...) would pass the >> >>      pte_pfn(x) -> (pte_val(x) >> PAGE_SHIFT) >> >> check. I don't think this applies, because >> >> While >>     #define _SEGMENT_ENTRY_ORIGIN_LARGE ~0xfffffUL >> >> We also have >> >>     #define _SEGMENT_ENTRY_ORIGIN ~0x7ffUL >> >> So these bits are not actually used. >> >> What __rste_to_pte() primarily does is reshuffling present bits etc. >> >> So using any other bits besides the PFN would be problematic I guess. >> >> Am I wrong or isn't the present bit already at a different location? For >> prot-none hugetlb folios there might be a real issue, as the PTE present bit >> corresponds to the PMD/PUD read-permission bit. >> >> >> Oh my :) >> >> So yeah, we should probably fix that ahead of time unless I am missing >> something? Good that we separate that hugetlb crap out. > > Yeah, looks like this was already there before the split. Should this > be fixed separately? Same bug is there in try_to_migrate_one(), check_pte(), remove_migration_pte() and prot_none_hugetlb_entry() :)