Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CABXGCsN3JqXckWO=V7p=FhPU1tK03RE1w9UE6xL5Y86SMk209w@mail.gmail.com>
 <b41e1b86-6280-5779-7bb7-3ba97481239@google.com>
In-Reply-To: <b41e1b86-6280-5779-7bb7-3ba97481239@google.com>
From:   Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Date:   Sun, 16 Jul 2023 14:53:58 +0500
Message-ID: <CABXGCsMaMgcPskMHPL+E=cOf9YMyaSnxg2dMa2jWO7qbjZGkjQ@mail.gmail.com>
Subject: Re: [bug/bisected] I see "mm/pgtable-generic.c:53: bad pmd
 (____ptrval____)(8000000100077061)" every boot time
To:     Hugh Dickins <hughd@google.com>
Cc:     Linux Memory Management List <linux-mm@kvack.org>,
        Linux List Kernel Mailing <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Sun, Jul 16, 2023 at 7:42=E2=80=AFAM Hugh Dickins <hughd@google.com> wro=
te:
>
> And thanks for the patient bisecting.  Yes, it will be 0d940a9b270b
> which introduced the unexpected problem, then be872f83bf5 which fixed
> the unbootability aspect (that's right, isn't it? with be872f83bf5 in,
> your machine booted ok? but in between it was unbootable).

Absolutely right.

> Very useful info, since it narrowed the symptom down to users of
> that pagewalker, before it was allowing for NULL from pte_offset_map()
> (we were not expecting ever to hit a bad pmd in normal circumstances).
>
> I have now been able to reproduce such a message, by setting
> CONFIG_EFI_PGT_DUMP=3Dy - am I guessing correctly that you have that?

Yes.
$ cat .config | grep CONFIG_EFI_PGT_DUMP
CONFIG_EFI_PGT_DUMP=3Dy

But distro Fedora has been set this setting to "Y" since 2016.
https://src.fedoraproject.org/rpms/kernel/blob/1b7eeb80190501aaf226e90e8f58=
f994cfc3efe0/f/kernel-x86_64-debug.config#_1293

commit 1b7eeb80190501aaf226e90e8f58f994cfc3efe0
Author: Laura Abbott <labbott@fedoraproject.org>
Date:   Thu Nov 10 10:16:25 2016 -0800

    Change method of configuration generation

    The existing method of managing configuration files gets unweildy.
    Changing individual lines in text files gets difficult without
    manual organization. Switch to a method of configuration generation
    that's inspired from the method used inside Red Hat. Each configuration
    option gets its own file which are then combined to form the
    configuration files. This makes confirming what's actually enabled much
    easier.

> For now, I recommend that you leave CONFIG_EFI_PGT_DUMP unset.
> I wonder how many other people have it set, but have not yet noticed
> this "bad pmd" message you are reporting.
>
> The problem comes from a confluence of surprises: the pagewalker
> now makes an exception for init_mm, but efi_mm is another odd case;
> and espfix sets up pmd entries in an unconventional way, which happens
> to fit the "bad pmd" criterion; then the efi_mm pgt dump discovers them.
>
> I'm not rushing to judgment on where and what the right fix will be,
> that needs some reflection.  And perhaps more urgent than that, is that
> I got not one but 12 such messages (with 4 processors): that's another
> surprise, I would have expected the condition to be cleared after the
> first message (but that clearing to ruin the running of Win16 binaries).
>
> More will follow, at lower priority; but if I'm wrong about you having
> CONFIG_EFI_PGT_DUMP=3Dy, and unsetting it hiding the issue, please speak =
up.

I confirm after unsetting CONFIG_EFI_PGT_DUMP the "bad pmd" message
didn't appear any more.

--=20
Best Regards,
Mike Gavrilov.