From nobody Wed Feb 11 07:07:40 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 204DA605C8 for ; Wed, 6 Mar 2024 10:42:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709721732; cv=none; b=m+B80v5fW928eBQdSitwM4Vw6rwR98DXAKq6igLOUjhMgWAvG07z9iSvdKjb5VEdn2YeCh100xhttIMQUG782LkUMl0UIiYTJgn4K3BmAwxhLsfcaXHyBShKPjLo0MFEWS2xGCrMa1ng2TnLI23/0G8UjkUtCunwAwDo9i3cRT8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709721732; c=relaxed/simple; bh=TOc5ZVxpN+gjn979gpSdbWiDJGT5Kkl4rfkIMqncNfo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hLjKnDlJT53eKA8GstsP4NWbHLtZb6n6UjaQnEAP4EesqgK/N4tFpaelzwEXeYunTxL4+MrfzJ55SAxrwpKd4CTaRBXrfk32DZxJ8RmKAV1A4aAUoOyI6AMvfs/0lQGuSN++WZs8uMemGYRi+mcEDidCgtnMzCmCpFlA+ZfL+UE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=OYLVYXF0; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="OYLVYXF0" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709721729; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=20nNimBrOEQv87l0vyMx8t0O66X6ZMzRQtOERvnhrUo=; b=OYLVYXF0Q3FH516eOTadMFuJ1FxoUjoGoN6h49kP8znMXzmUDfEiXVx+ryyoALMSfZukmw FPGGSwjjnWKTMNWJsg2Q5016DO7b/0AL07psN4DxKitcKg59xXmu8SDLdlNAPPACoDb2Xe KcZAt+FgGNXsRu7C8VTx7sMerukt7Zg= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-651-oo52lPpuOsCDdbHCtpeneA-1; Wed, 06 Mar 2024 05:42:04 -0500 X-MC-Unique: oo52lPpuOsCDdbHCtpeneA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id C7D471C05AF3; Wed, 6 Mar 2024 10:42:03 +0000 (UTC) Received: from x1n.redhat.com (unknown [10.72.116.8]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3C2C5112131D; Wed, 6 Mar 2024 10:41:56 +0000 (UTC) From: peterx@redhat.com To: linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org, Andrew Morton , Muchun Song , Jason Gunthorpe , peterx@redhat.com, Matthew Wilcox , Mike Rapoport , Christophe Leroy , x86@kernel.org, sparclinux@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Alistair Popple Subject: [PATCH RFC 01/13] mm/hmm: Process pud swap entry without pud_huge() Date: Wed, 6 Mar 2024 18:41:35 +0800 Message-ID: <20240306104147.193052-2-peterx@redhat.com> In-Reply-To: <20240306104147.193052-1-peterx@redhat.com> References: <20240306104147.193052-1-peterx@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.3 Content-Type: text/plain; charset="utf-8" From: Peter Xu Swap pud entries do not always return true for pud_huge() for all archs. x86 and sparc (so far) allow it, but all the rest do not accept a swap entry to be reported as pud_huge(). So it's not safe to check swap entries within pud_huge(). Check swap entries before pud_huge(), so it should be always safe. This is the only place in the kernel that (IMHO, wrongly) relies on pud_huge() to return true on pud swap entries. The plan is to cleanup pXd_huge() to only report non-swap mappings for all archs. Cc: Alistair Popple Signed-off-by: Peter Xu Reviewed-by: Jason Gunthorpe --- mm/hmm.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/mm/hmm.c b/mm/hmm.c index 277ddcab4947..c44391a0246e 100644 --- a/mm/hmm.c +++ b/mm/hmm.c @@ -424,7 +424,7 @@ static int hmm_vma_walk_pud(pud_t *pudp, unsigned long = start, unsigned long end, walk->action =3D ACTION_CONTINUE; =20 pud =3D READ_ONCE(*pudp); - if (pud_none(pud)) { + if (pud_none(pud) || !pud_present(pud)) { spin_unlock(ptl); return hmm_vma_walk_hole(start, end, -1, walk); } @@ -435,11 +435,6 @@ static int hmm_vma_walk_pud(pud_t *pudp, unsigned long= start, unsigned long end, unsigned long *hmm_pfns; unsigned long cpu_flags; =20 - if (!pud_present(pud)) { - spin_unlock(ptl); - return hmm_vma_walk_hole(start, end, -1, walk); - } - i =3D (addr - range->start) >> PAGE_SHIFT; npages =3D (end - addr) >> PAGE_SHIFT; hmm_pfns =3D &range->hmm_pfns[i]; --=20 2.44.0