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 2D99AC25B76 for ; Thu, 6 Jun 2024 00:25:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 903C46B009A; Wed, 5 Jun 2024 20:25:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 861786B00A2; Wed, 5 Jun 2024 20:25:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6DB516B00A3; Wed, 5 Jun 2024 20:25:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 4BBA56B009A for ; Wed, 5 Jun 2024 20:25:37 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id D6952A2C9C for ; Thu, 6 Jun 2024 00:25:36 +0000 (UTC) X-FDA: 82198570272.12.4366EDB Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) by imf19.hostedemail.com (Postfix) with ESMTP id 18FDA1A000F for ; Thu, 6 Jun 2024 00:25:34 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=wHaDcJk5; spf=pass (imf19.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.222.179 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=pass (policy=none) header.from=soleen.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717633535; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=G1s4PX2KCyvcBADkbBYVK0pP1bkY3AHPso5o+d0yEf4=; b=trCu0vz6jVmSVj2N5/h5kmKorbraMWRfsQBQqBuZA3vp0zY34dxYAQEHbwTQaLkoL53jZL 0QoLv2ba4Kkq6iA5PnzcmZO1FM7xOrhtI4VE/bEyMhrS0RhYjcIcuUir7AoXhHIZAo/V/7 pZ1hnghYplZoOxM4qR/sX2xKwYl+UfU= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=wHaDcJk5; spf=pass (imf19.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.222.179 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=pass (policy=none) header.from=soleen.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717633535; a=rsa-sha256; cv=none; b=vdI/KystCf4SBrhtLByVCvUA+9R9Hj/xGKbcb5HJrxUlomWEKRK3+eaZeuKMFoNe7KCozB AlShzm7kP4Q1knv1ZcrmAkulxMlOvIBhoaJaF4wg8rak3G0Nh6QEgj0EA05P4Wa5sww+Hi 37ynHsv1AzZur7jpAPKrsVhuslmYckE= Received: by mail-qk1-f179.google.com with SMTP id af79cd13be357-7951e24db3bso18336485a.3 for ; Wed, 05 Jun 2024 17:25:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen-com.20230601.gappssmtp.com; s=20230601; t=1717633534; x=1718238334; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=G1s4PX2KCyvcBADkbBYVK0pP1bkY3AHPso5o+d0yEf4=; b=wHaDcJk5r3SDO4LaZ8Rl0vEUk0yoNbHZw/mSdReIu1hoHymXGLXo1D/jicAgfZft/I KdYfOq13aTHZEt3nTsMf2aFLqYNpnBbUsi7SkYclXskEpJgcxHXjYfLtaBX42xde1D9W 5YWzqEIt+llatOTl6PvAPXZGGPeFdwnp86uqjY0Ro/XUGCh7bPo9t6+5RABMplq9o13Y dSqS6l/dXEejC4jhEDrV2sdoxwYT0xtbgOFX8JKdFVl71+I4eNOP/v1C24e0DFJ9me3A ZRUa9MOvEPyK+yJronY6kMuJmIAYAeDWeTDUDM+MEQ3zvWPymQDUoJxnGE9f9aHl5pjc OohA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717633534; x=1718238334; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=G1s4PX2KCyvcBADkbBYVK0pP1bkY3AHPso5o+d0yEf4=; b=l9m1U98FkyQC9ySxcHM/khedMnwxTctxwwND74zwUxETJvkt2cR1ITswvq/zO5DLHG gNA2/bSV/cU55600OF0VB0ANB2lGs5zikRzNo86rZVjvYztdHuFng6BzllC0X7BBa+0j 98/R/keZkQ8zxWIhaard53PvYNW4A5xTmzAYQUoEuBPAMiOwE1QStXJ34C8W84u9ZrZE gEkpxnYWSweJpP0urGkJp1NYgzZJBiWJ4toGquusSf8YmVCok8cHchzrg+9OwMqfEXYT YhlHWntRWTzHg9/sie6rm5IDYLxhBKi1vYg1s+qNsWp2aaljUj67KeBPm86U72giGs8b 3GDA== X-Forwarded-Encrypted: i=1; AJvYcCUPKNf6V6KDoxM2+DfrJJv/SsAI7x1nx+xxptAemAFG9cMVd2YD98UqozeYxxrS2MWo/wmbyzH2D6+MDsF16Fk6gDA= X-Gm-Message-State: AOJu0YwN+Rug891b5GMT3tkItP5t9GsmpHD2CEU3gzAItbgdKLdP8xJX PQ7HxPR5aivbKA+A5NQesKokCYc9Nq3sP7PwOmTdwCuI6HdX4OjPj4przN+hM3rZEMcHCEPfbUG jUMkKaqbgCk95k3vIsgr3DEq1VUGXHSny5DRt3Q== X-Google-Smtp-Source: AGHT+IEv5O+VTVcNzKe+sdpf8DdQPjO4FPLYUjb0gFxY2yKveF0NVL6NkUVNTkQHOMsQhotZMBaeOCsjA535Rk9etHw= X-Received: by 2002:a05:620a:4d3:b0:792:91e0:e236 with SMTP id af79cd13be357-79523d6df6fmr425892385a.30.1717633534136; Wed, 05 Jun 2024 17:25:34 -0700 (PDT) MIME-Version: 1.0 References: <20240605212146.994486-1-peterx@redhat.com> <666100d39dee4_2d412294b3@dwillia2-mobl3.amr.corp.intel.com.notmuch> In-Reply-To: <666100d39dee4_2d412294b3@dwillia2-mobl3.amr.corp.intel.com.notmuch> From: Pasha Tatashin Date: Wed, 5 Jun 2024 20:24:55 -0400 Message-ID: Subject: Re: [PATCH] mm/page_table_check: Fix crash on ZONE_DEVICE To: Dan Williams Cc: Peter Xu , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 18FDA1A000F X-Stat-Signature: 6w6iknfe4oktd1ty4f7pjboi1389tbw5 X-Rspam-User: X-HE-Tag: 1717633534-139025 X-HE-Meta: U2FsdGVkX1/P/YJd7jKhs5+zIS1+a7BlZJOhqEQbr0nEKyxCHtA4m4HdNnxJBUxvok9zUayPqBAJ+xZggDYiol3qzZnb/n35OMw2Cq3a5D/cBUpgSmb5KPw4Is40f1ycERTCJkxlBmBQJOJcB/arP9GisPFw81fPyGMUSNwBDENy9HznVDr8lDJLhuwiuCiis0ZqGg3lvQABuUqWZz40PtysHGWW5v3PUReLdXIkKgUd+vzwEkQEg5mCfUs3f5POM41KNysgU8veWmy00Hp5AFCNMMBlpMu7V80dpHJbWOvGqh8vJCWWNbLXBm8FAvfuK9P1+bIUSMroJbjJf8XRLZXHRAIeKesjXEXr7tYPV2+NUOMQ5h0QdtC2I4I6fYcAf0q2ZD6othQVFlCpusLgIaD50Nm3KRQ4q1ItFos95unaDAYt0Xz7/P5Nn1qtjmm9SrjKmEfSJwyiwYirvFQz1YuheHAydwywlk+Zw9FUu97pKgXNeVUPh87pdr34cvRHwz47LVTMZqru1wfIghot16ZaAAaEKPYqZowQi0/KLn2L267Cl6nKPIfWdJwa7AyJKYRr27+6RrqT+ReIYFSJfF2+u3/TSmZOJ80mqoL5pWv5vztebZIxnmufxGPdCjfsstUw514qqHtgVnn1rl3kmugOSFGqzQBkK2Z7FoU+i1gOPDDjfxN2YcDn/Fr8fKJzAaI/S7E9EXHu1Qqu/1WCQJXqLMr0ha/gq3J1F8udNMAWkxTQxlttmPRm9AZt8RyJtZbz8v1NV0lmpXHs0sL3/yrbjcJ5seT7br3hA2BJjybhodtPcjCymZHmrZns6KldoJkfm0Pd5lQRHy/zcLZ5t+B9h/o8qfBz7WMCZSxrcHz7FNALkZQ+tvYCqj91HXH65lqze+rXrrlGIWNsUyOmSfe3ly0t2e9XA1czTOpaBPiuHWIuZ5Rtx7SkzD5g2NTuqtZfij/rGZ8MRzQt+v+ h+EN6APu ciZh6k8UkjIvA/Gte0iTxhX1QXSgfW2fxGcGJrZjAHXjUAaIzVsZegYP1DUVrAhuoRVWuCAybEe7Gs3SRGUkbp70uQdkYwXVLdWuGPue9bbZ1Qt623f3tkUDlE94ZbfKy2CAUwBCn1raJmXMjwkUJeCSoICD8+l6sgxvhco/Na7SpASnQC8CzKDhNO13Unj+EyecJOcjtc7ub8CFv8795DiN101hHMCJWxB3aJ2MzDb91xgCSohA5xfg4Z3fEEYtGW3ai9L+8So9quaJVkKeB05S7Ht0dxRra2I26I3nTDOA8e1SLieq1wWCy+UrBUy7gWoziFgR49MvfBLkCbeZ6qcnGE1j1zpHknYK/uAJ72GXSPr04FB/iBZLrKGAAY2T9Wt1M882gsdU8wbC3pU2dH6elBxSAS7RzT7pMgvX8uSz3Ut9dJ0qffvN5Vw== 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: List-Subscribe: List-Unsubscribe: On Wed, Jun 5, 2024 at 8:20=E2=80=AFPM Dan Williams wrote: > > Pasha Tatashin wrote: > > On Wed, Jun 5, 2024 at 5:21=E2=80=AFPM Peter Xu wro= te: > > > > > > Not all pages may apply to pgtable check. One example is ZONE_DEVICE > > > pages: they map PFNs directly, and they don't allocate page_ext at al= l even > > > if there's struct page around. One may reference devm_memremap_pages= (). > > > > > > When both ZONE_DEVICE and page-table-check enabled, then try to map s= ome > > > dax memories, one can trigger kernel bug constantly now when the kern= el was > > > trying to inject some pfn maps on the dax device: > > > > > > kernel BUG at mm/page_table_check.c:55! > > > > > > While it's pretty legal to use set_pxx_at() for ZONE_DEVICE pages for= page > > > fault resolutions, skip all the checks if page_ext doesn't even exist= in > > > pgtable checker, which applies to ZONE_DEVICE but maybe more. > > > > Thank you for reporting this bug. A few comments below: > > > > > > > > Cc: Dan Williams > > > Cc: Pasha Tatashin > > > Signed-off-by: Peter Xu > > > --- > > > mm/page_table_check.c | 11 ++++++++++- > > > 1 file changed, 10 insertions(+), 1 deletion(-) > > > > > > diff --git a/mm/page_table_check.c b/mm/page_table_check.c > > > index 4169576bed72..509c6ef8de40 100644 > > > --- a/mm/page_table_check.c > > > +++ b/mm/page_table_check.c > > > @@ -73,6 +73,9 @@ static void page_table_check_clear(unsigned long pf= n, unsigned long pgcnt) > > > page =3D pfn_to_page(pfn); > > > page_ext =3D page_ext_get(page); > > > > > > + if (!page_ext) > > > + return; > > > > I would replace the above with the following, here and in other places: > > > > if (!page_ext) { > > WARN_ONCE(!is_zone_device_page(page), > > "page_ext is missing for a non-device page\n"= ); > > return; > > } > > Hmm, but this function is silent for the !pfn_valid(@pfn) case, and the > old cold has BUG_ON(!page_ext). So we know the caller is not being > careful about @pfn, and existing code is likely avoiding the BUG_ON(). > > The justification for the WARN_ONCE(), or maybe VM_WARN_ONCE(), would > be if there is a high likelihood that ongoing kernel changes introduce > more pfn_valid() but not page_ext covered pages? Is that a realistic > scenario? Good point, it is unlikely we will have scenarios without page_ext. Reviewed-by: Pasha Tatashin