All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	patches@lists.linux.dev, Helge Deller <deller@gmx.de>,
	Borislav Petkov <bp@suse.de>, Guenter Roeck <linux@roeck-us.net>,
	Peter Zijlstra <peterz@infradead.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: [PATCH 6.4 7/9] lockdep: fix static memory detection even more
Date: Thu, 31 Aug 2023 13:11:34 +0200	[thread overview]
Message-ID: <20230831111128.017245084@linuxfoundation.org> (raw)
In-Reply-To: <20230831111127.667900990@linuxfoundation.org>

6.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Helge Deller <deller@gmx.de>

commit 0a6b58c5cd0dfd7961e725212f0fc8dfc5d96195 upstream.

On the parisc architecture, lockdep reports for all static objects which
are in the __initdata section (e.g. "setup_done" in devtmpfs,
"kthreadd_done" in init/main.c) this warning:

	INFO: trying to register non-static key.

The warning itself is wrong, because those objects are in the __initdata
section, but the section itself is on parisc outside of range from
_stext to _end, which is why the static_obj() functions returns a wrong
answer.

While fixing this issue, I noticed that the whole existing check can
be simplified a lot.
Instead of checking against the _stext and _end symbols (which include
code areas too) just check for the .data and .bss segments (since we check a
data object). This can be done with the existing is_kernel_core_data()
macro.

In addition objects in the __initdata section can be checked with
init_section_contains(), and is_kernel_rodata() allows keys to be in the
_ro_after_init section.

This partly reverts and simplifies commit bac59d18c701 ("x86/setup: Fix static
memory detection").

Link: https://lkml.kernel.org/r/ZNqrLRaOi/3wPAdp@p100
Fixes: bac59d18c701 ("x86/setup: Fix static memory detection")
Signed-off-by: Helge Deller <deller@gmx.de>
Cc: Borislav Petkov <bp@suse.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 arch/x86/include/asm/sections.h |   18 ------------------
 kernel/locking/lockdep.c        |   36 ++++++++++++++----------------------
 2 files changed, 14 insertions(+), 40 deletions(-)

--- a/arch/x86/include/asm/sections.h
+++ b/arch/x86/include/asm/sections.h
@@ -2,8 +2,6 @@
 #ifndef _ASM_X86_SECTIONS_H
 #define _ASM_X86_SECTIONS_H
 
-#define arch_is_kernel_initmem_freed arch_is_kernel_initmem_freed
-
 #include <asm-generic/sections.h>
 #include <asm/extable.h>
 
@@ -18,20 +16,4 @@ extern char __end_of_kernel_reserve[];
 
 extern unsigned long _brk_start, _brk_end;
 
-static inline bool arch_is_kernel_initmem_freed(unsigned long addr)
-{
-	/*
-	 * If _brk_start has not been cleared, brk allocation is incomplete,
-	 * and we can not make assumptions about its use.
-	 */
-	if (_brk_start)
-		return 0;
-
-	/*
-	 * After brk allocation is complete, space between _brk_end and _end
-	 * is available for allocation.
-	 */
-	return addr >= _brk_end && addr < (unsigned long)&_end;
-}
-
 #endif	/* _ASM_X86_SECTIONS_H */
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -817,34 +817,26 @@ static int very_verbose(struct lock_clas
  * Is this the address of a static object:
  */
 #ifdef __KERNEL__
-/*
- * Check if an address is part of freed initmem. After initmem is freed,
- * memory can be allocated from it, and such allocations would then have
- * addresses within the range [_stext, _end].
- */
-#ifndef arch_is_kernel_initmem_freed
-static int arch_is_kernel_initmem_freed(unsigned long addr)
-{
-	if (system_state < SYSTEM_FREEING_INITMEM)
-		return 0;
-
-	return init_section_contains((void *)addr, 1);
-}
-#endif
-
 static int static_obj(const void *obj)
 {
-	unsigned long start = (unsigned long) &_stext,
-		      end   = (unsigned long) &_end,
-		      addr  = (unsigned long) obj;
+	unsigned long addr = (unsigned long) obj;
 
-	if (arch_is_kernel_initmem_freed(addr))
-		return 0;
+	if (is_kernel_core_data(addr))
+		return 1;
+
+	/*
+	 * keys are allowed in the __ro_after_init section.
+	 */
+	if (is_kernel_rodata(addr))
+		return 1;
 
 	/*
-	 * static variable?
+	 * in initdata section and used during bootup only?
+	 * NOTE: On some platforms the initdata section is
+	 * outside of the _stext ... _end range.
 	 */
-	if ((addr >= start) && (addr < end))
+	if (system_state < SYSTEM_FREEING_INITMEM &&
+		init_section_contains((void *)addr, 1))
 		return 1;
 
 	/*



  parent reply	other threads:[~2023-08-31 11:12 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-31 11:11 [PATCH 6.4 0/9] 6.4.14-rc1 review Greg Kroah-Hartman
2023-08-31 11:11 ` [PATCH 6.4 1/9] ACPI: thermal: Drop nocrt parameter Greg Kroah-Hartman
2023-08-31 11:11 ` [PATCH 6.4 2/9] module/decompress: use vmalloc() for zstd decompression workspace Greg Kroah-Hartman
2023-08-31 11:11 ` [PATCH 6.4 3/9] module: Expose module_init_layout_section() Greg Kroah-Hartman
2023-08-31 11:11 ` [PATCH 6.4 4/9] arm64: module-plts: inline linux/moduleloader.h Greg Kroah-Hartman
2023-08-31 11:11 ` [PATCH 6.4 5/9] arm64: module: Use module_init_layout_section() to spot init sections Greg Kroah-Hartman
2023-08-31 11:11 ` [PATCH 6.4 6/9] ARM: " Greg Kroah-Hartman
2023-08-31 11:11 ` Greg Kroah-Hartman [this message]
2023-08-31 11:11 ` [PATCH 6.4 8/9] parisc: sys_parisc: parisc_personality() is called from asm code Greg Kroah-Hartman
2023-08-31 11:11 ` [PATCH 6.4 9/9] kallsyms: Fix kallsyms_selftest failure Greg Kroah-Hartman
2023-08-31 21:26 ` [PATCH 6.4 0/9] 6.4.14-rc1 review Florian Fainelli
2023-09-01  1:04 ` SeongJae Park
2023-09-01  6:13 ` Ron Economos
2023-09-01  7:02 ` Bagas Sanjaya
2023-09-01  9:46 ` Sudip Mukherjee (Codethink)
2023-09-01 10:37 ` Naresh Kamboju
2023-09-01 13:42 ` Justin Forbes
2023-09-01 15:22 ` Shuah Khan
2023-09-01 18:46 ` Jon Hunter
2023-09-02  4:19 ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230831111128.017245084@linuxfoundation.org \
    --to=gregkh@linuxfoundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=bp@suse.de \
    --cc=deller@gmx.de \
    --cc=linux@roeck-us.net \
    --cc=patches@lists.linux.dev \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.