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;
Date:   Thu, 17 Nov 2022 14:58:37 +0100
From:   Marco Elver <elver@google.com>
To:     Naresh Kamboju <naresh.kamboju@linaro.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Dave Hansen <dave.hansen@intel.com>
Cc:     kasan-dev <kasan-dev@googlegroups.com>, X86 ML <x86@kernel.org>,
        open list <linux-kernel@vger.kernel.org>,
        linux-mm <linux-mm@kvack.org>, regressions@lists.linux.dev,
        lkft-triage@lists.linaro.org,
        Andrew Morton <akpm@linux-foundation.org>,
        Alexander Potapenko <glider@google.com>
Subject: Re: WARNING: CPU: 0 PID: 0 at arch/x86/include/asm/kfence.h:46
 kfence_protect
Message-ID: <Y3Y+DQsWa79bNuKj@elver.google.com>
References: <CA+G9fYuFxZTxkeS35VTZMXwQvohu73W3xbZ5NtjebsVvH6hCuA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+G9fYuFxZTxkeS35VTZMXwQvohu73W3xbZ5NtjebsVvH6hCuA@mail.gmail.com>
User-Agent: Mutt/2.2.7 (2022-08-07)
Precedence: bulk

On Thu, Nov 17, 2022 at 05:01PM +0530, Naresh Kamboju wrote:
> Kunit test cases failed and found warnings while booting Linux next
> version 6.1.0-rc5-next-20221117 on qemu-x86_64 [1].
> 
> It was working on Linux next-20221116 tag.
> 
> [    0.663761] WARNING: CPU: 0 PID: 0 at
> arch/x86/include/asm/kfence.h:46 kfence_protect+0x7b/0x120
> [    0.664033] WARNING: CPU: 0 PID: 0 at mm/kfence/core.c:234
> kfence_protect+0x7d/0x120
> [    0.664465] kfence: kfence_init failed
> 
> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
[...]
> [    0.663758] ------------[ cut here ]------------
> [    0.663761] WARNING: CPU: 0 PID: 0 at
> arch/x86/include/asm/kfence.h:46 kfence_protect+0x7b/0x120
[...]
> [    0.664465] kfence: kfence_init failed
> 
> metadata:
>   git_ref: master
>   git_repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next
>   git_sha: af37ad1e01c72483c4ee8453d9d9bac95d35f023
>   git_describe: next-20221117
>   kernel_version: 6.1.0-rc5
>   kernel-config: https://builds.tuxbuild.com/2Hfb6n1z0frt4iBlIvqUzjMHiLm/config
>   build-url: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next/-/pipelines/697483979
>   artifact-location: https://builds.tuxbuild.com/2Hfb6n1z0frt4iBlIvqUzjMHiLm
>   toolchain: gcc-11

I bisected this to:

	commit 127960a05548ea699a95791669e8112552eb2452
	Author: Peter Zijlstra <peterz@infradead.org>
	Date:   Thu Nov 10 13:33:57 2022 +0100

	    x86/mm: Inhibit _PAGE_NX changes from cpa_process_alias()

	    There is a cludge in change_page_attr_set_clr() that inhibits
	    propagating NX changes to the aliases (directmap and highmap) -- this
	    is a cludge twofold:

	     - it also inhibits the primary checks in __change_page_attr();
	     - it hard depends on single bit changes.

	    The introduction of set_memory_rox() triggered this last issue for
	    clearing both _PAGE_RW and _PAGE_NX.

	    Explicitly ignore _PAGE_NX in cpa_process_alias() instead.

	    Fixes: b38994948567 ("x86/mm: Implement native set_memory_rox()")
	    Reported-by: kernel test robot <oliver.sang@intel.com>
	    Debugged-by: Dave Hansen <dave.hansen@intel.com>
	    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
	    Link: https://lkml.kernel.org/r/20221110125544.594991716%40infradead.org

A simple revert of this commit fixes the issue.

Since all this seems to be about set_memory_rox(), and this is a fix
commit, the fix itself missed something?

Thanks,
-- Marco