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 ED789C27C40 for ; Thu, 24 Aug 2023 14:47:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 198D1280080; Thu, 24 Aug 2023 10:47:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 148FF8E0015; Thu, 24 Aug 2023 10:47:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 01051280080; Thu, 24 Aug 2023 10:47:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id E329D8E0015 for ; Thu, 24 Aug 2023 10:47:44 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 94041803AF for ; Thu, 24 Aug 2023 14:47:43 +0000 (UTC) X-FDA: 81159277206.29.608D7C2 Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) by imf13.hostedemail.com (Postfix) with ESMTP id BBFA320008 for ; Thu, 24 Aug 2023 14:47:41 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=kmKIEqvd; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of zokeefe@google.com designates 209.85.208.50 as permitted sender) smtp.mailfrom=zokeefe@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692888461; a=rsa-sha256; cv=none; b=ZwTcwlEIiYL6Anw44F4px5GWgulduEpbsqsHbeJxkxyPfa+xjm512DafGoQgo8UWBk6SiS ZB8o5ArU7itOI+KI3Ih+wWQwnyuypZ5TViDxXKGhjWrX6L2ob6FHbJ1UWf6K9D6Yinpumi kZGzKJNYMFWCdQ7I9DmeMnfI+g1d4Nc= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=kmKIEqvd; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of zokeefe@google.com designates 209.85.208.50 as permitted sender) smtp.mailfrom=zokeefe@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692888461; 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=szLdS5RHFFJmIl7dIQZZUJMa64tgdaaz20ssbXi59gY=; b=btxpfkk1lMeP//bj4rUZO4BOt7uwv+xh2JEjW9LNTiC88o064VZ/sGghB76VXtCRTFWWxP gCNmXHtStQKUqsw7AO4aAqhLheOSOeBcrgCLV+wMJQbzxCm/U/lpG7Oj1L3POknKwCDD4z ApFXbPbiWuFAlSdfsG0m99iSZyi4gDQ= Received: by mail-ed1-f50.google.com with SMTP id 4fb4d7f45d1cf-529fa243739so14303a12.0 for ; Thu, 24 Aug 2023 07:47:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1692888460; x=1693493260; 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=szLdS5RHFFJmIl7dIQZZUJMa64tgdaaz20ssbXi59gY=; b=kmKIEqvd24XXY6uu+5/LT7T+U5p41NS37rhYUrrrSZsW7XLuehJAgWg1GGZHH97atJ KJU25Sz93DlgTj3MsZdq8FpAKs8fDP4iLLa7lOL9CCRza67xhRkTB7UogfAfYWqbNHGB V4BurqsDsqVimyNEFpqwNraJrKFNCF7ZgAn+TT/BPlF3o83+aAx8BGbzWPPkr/QO6N94 o/48f/GMXt3gJInH9CUGLE7Ap1UoPXWQQdsFs7QavWE2b90O9EJ+ofZgSZKR1Yyzf1V9 1qy/LEm8fkvY6xPNJPXdP/y9V98VH/dChtloet0qkpoMLZjIWzBM71YHWGskb8womw9l WhRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692888460; x=1693493260; 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=szLdS5RHFFJmIl7dIQZZUJMa64tgdaaz20ssbXi59gY=; b=R1d8j0aNb+0CMemlW8KWNGYt3/qepx1DI9lu2aPSw0k7vFiKBI8W4xt4TGq7m1n0ne ABB1uVTb9BGJsIm2TaFhSP/fYzNdz95ErTOhOJeGHv634Bw6U/G6+2GDBnOHqXrXrATd u0BL3N/Yqj9GudPmjh5v3oh+KFbSM7kJCg4AKiTd1hpYsbDlqC+Ss/GTY/DQIxqeRjq4 wM43Y+iIhhj/PVn5HfonbJBRB+919Kd+JE820N/12uGH0alUG4Gcd1bkeu8cvomaQ3wl skbLD5/Ytq8GCiH94/Hf15gLR9q3wwlASen/rvHYmwnnsY5NV0ZJ1NaAYcBatw1C9cTb QYPA== X-Gm-Message-State: AOJu0YxI4zAU9w5gT9CnNjsI8Ojt3jO3Fg0p3ingt98InMxf2JHAhuz/ zs3sJzva4c/ZmoWtJVuyS+TjNu3fJs2src2aK/9QSgfIl8DmFi7GVeI= X-Google-Smtp-Source: AGHT+IE0Pu693JS2IW8sE0A491+67g8cNurIxmbz+9zZJGDLJtooGOIT0OlxBA2MbO5JKk6Jxvz7ZZz+XUFT5pfSiqc= X-Received: by 2002:a50:9b1e:0:b0:523:193b:5587 with SMTP id o30-20020a509b1e000000b00523193b5587mr430490edi.6.1692888460224; Thu, 24 Aug 2023 07:47:40 -0700 (PDT) MIME-Version: 1.0 References: <20230821234844.699818-1-zokeefe@google.com> <37c2b525-5c2c-d400-552c-9ccb91f4d7bf@redhat.com> <3e08d48b-7b70-cc7f-0ec1-12ad9b1a33db@redhat.com> In-Reply-To: <3e08d48b-7b70-cc7f-0ec1-12ad9b1a33db@redhat.com> From: "Zach O'Keefe" Date: Thu, 24 Aug 2023 07:47:03 -0700 Message-ID: Subject: Re: [PATCH v3] mm/thp: fix "mm: thp: kill __transhuge_page_enabled()" To: David Hildenbrand Cc: linux-mm@kvack.org, Yang Shi , linux-kernel@vger.kernel.org, Saurabh Singh Sengar , Greg KH Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: BBFA320008 X-Stat-Signature: fmidkmc55bs6kjqu7za7pgz9imk37rbg X-HE-Tag: 1692888461-1484 X-HE-Meta: U2FsdGVkX18ye0BEMOVk79mTD7jkVhwnlM5SuoNU4VdbmQMq0BEjRh0BDftPgBzwRE9vVi3XaGqoHSFzGKq3P83np1MqY7/fc7vSxGI8UwnCLbMotOc/iZ4+GCO7SL9AVUdwKt3w3xuuSqJ6hPKkBFqU46U11RNpf34OyS+5hAQEEze0Yuab7thCKxZvWYeqeYCH/jA24h+TKugDPLD99ZAlULvWZZr3gM1kSN9pRCzNvpRZzVF7yAzKTXqLN+irzvGHUZSBhjmPIlhcIN2mmZAQzSaDK16gX4z1xa5cIcRJphKQGcYRcHgUn8/aHbXWMMRqeddBCOFORClNOuy6qpJQ25JrOdp6J+tjkJonIhxtOekTBNOKqNWFNm77rlFDYUEEqRfEfp9fVXJ14fX9vZoYxFF08my/ILI8/PXMCm3o880ZVwYvYinN+Mnbn906zHHwDz8SGOYpZU1zqG1SxQaKpvmiiFTNlE2MY2BmbqJP/MX18/76XRzyQCJJWEnc/23hSNLOHFmGJZMfC0lCxz1dF23e4058qzdXRXur8i+2NegGLkL00bAxOvPd+vEwZOnGIr4JcR6wL15JH+j18z0y3huu00hx23Jm6Bp1kqXlJXGFDLJJ/8Hf/M4kDmZ0JnDzF29js/+DV76n/EZ8q3WIdS77P/OR4vTHp1Sw011CiSnyhwJ0mODLXotzBTygAdqGKI/nIR0jvdmcGbywlDwFS4fs74wlGsTaZZ90QNQ5dNcbGJ1/mKAkvLdChVwa6islzqarCFYlqk0fubD5iLLah3wEEW0MAfZ0Hxp4f14cN9/Zu6awSMw8/0yGCbZRHR6vEfg/4kEgAb8mtKaXhsZDzsQ+MBc4aMZjDJ4MpZRDZj3ua9Hr1MlhLCJzc1hWN/3TaOxmJalQVn4pVZTCKj+HU+tbLVeJA+e7gVvwlSKsQdvpA35L2Ry2sOfKsJy62ll9JEa6I8p1RECTRFI MrimYJu5 xZV8jXXi651FUaLYiisq79VB2Hj/fz9Bk6jPbJJxAo0FYU3WxTaJG2gD0gmCA5ezgWjfoken7ONniA/DPtYuTt85h6vJT0qiaZ/ncFAQ7ZGixTiTwTYfsJVtL8f5z7kbLUFGU+Wo5OV5/KBdYLWts6/KT/LoAoDXqTMOazf0CibZuWGtWyreLCp2M+CLH3jjhzoSfL3EKhT9ALGOtiPs8RiwSGyGtZGVCk+X88PwYkhd185g9ImW7FlG8ycge/GNbajpSXAPfCTHt6f+m5r9EC2WsW87+DlRh6L8aue89hud0tTU= 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: On Thu, Aug 24, 2023 at 7:05=E2=80=AFAM David Hildenbrand wrote: > > On 24.08.23 15:59, Zach O'Keefe wrote: > > On Thu, Aug 24, 2023 at 12:39=E2=80=AFAM David Hildenbrand wrote: > >> > >> On 22.08.23 01:48, Zach O'Keefe wrote: > >>> The 6.0 commits: > >>> > >>> commit 9fec51689ff6 ("mm: thp: kill transparent_hugepage_active()") > >>> commit 7da4e2cb8b1f ("mm: thp: kill __transhuge_page_enabled()") > >>> > >>> merged "can we have THPs in this VMA?" logic that was previously done > >>> separately by fault-path, khugepaged, and smaps "THPeligible" checks. > >>> > >>> During the process, the semantics of the fault path check changed in = two > >>> ways: > >>> > >>> 1) A VM_NO_KHUGEPAGED check was introduced (also added to smaps path)= . > >>> 2) We no longer checked if non-anonymous memory had a vm_ops->huge_fa= ult > >>> handler that could satisfy the fault. Previously, this check ha= d been > >>> done in create_huge_pud() and create_huge_pmd() routines, but af= ter > >>> the changes, we never reach those routines. > >>> > >>> During the review of the above commits, it was determined that in-tre= e > >>> users weren't affected by the change; most notably, since the only re= levant > >>> user (in terms of THP) of VM_MIXEDMAP or ->huge_fault is DAX, which i= s > >>> explicitly approved early in approval logic. However, there is at le= ast > >>> one occurrence where an out-of-tree driver that used > >>> VM_HUGEPAGE|VM_MIXEDMAP with a vm_ops->huge_fault handler, was broken= . > >> > >> ... so all we did is break an arbitrary out-of-tree driver? Sorry to > >> say, but why should we care? > >> > >> Is there any in-tree code affected and needs a "Fixes:" ? > > > > The in-tree code was taken care of during the rework .. but I didn't > > know about the possibility of a driver hooking in here. > > And that's the problem of the driver, no? It's not the job of the kernel > developers to be aware of each out-of-tree driver to not accidentally > break something in there. > > > > > I don't know what the normal policy / stance here is, but I figured > > the change was simple enough that it was worth helping out. > > If you decide to be out-of-tree, then you have be prepared to only > support tested kernels and fix your driver when something changes > upstream -- like upstream developers would do for you when it would be > in-tree. > > So why can't the out-of-tree driver be fixed, similarly to how we would > have fixed it if it would be in-tree? I don't know much about driver development, but perhaps they are / need to use a pristine upstream kernel, with their driver as a loadable kernel module. Saurabh can comment on this, I don't know. But your point is very valid otherwise. > -- > Cheers, > > David / dhildenb >