GNU Binutils 2.33.1 has been released.

[Alan Modra]

On Sat, Nov 30, 2019 at 12:05:55PM +0100, Romain Naour wrote:
> The system doesn't boot but if It I revert the commit [1], the system boot.
> 
> Since it's a commit not related to sh4, it's weird that is the only affected
> architecture.
> 
> [1]
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ebd2263ba9a9124d93bbc0ece63d7e0fae89b40e

Difference in vmlinux linker map file (I added -Map vmlinux.map to ld
flags) between 2.33.1 and 2.33.1 with [1] reverted is:

                 0x000000008c3ff5b0       0x11 lib/timerqueue.o
  *fill*         0x000000008c3ff5c1        0x3 
  .rodata.str1.4
-                0x000000008c3ff5c4      0x13f lib/vsprintf.o
+                0x000000008c3ff5c4      0x140 lib/vsprintf.o
                                         0x1bf (size before relaxing)
-                0x000000008c3ff703                __start_ro_after_init = .
+                0x000000008c3ff704                __start_ro_after_init = .
  *(.data..ro_after_init)
- *fill*         0x000000008c3ff703        0x1 
  .data..ro_after_init
                 0x000000008c3ff704       0x1c kernel/ksysfs.o
  .data..ro_after_init

I believe there is a kernel bug in handling of __start_ro_after_init.
If you take a look at kmemleak.c:scan_block you'll see that the start
address is aligned up to a pointer sized boundary.  That's fine, but
scan_large_block calls scan_block repeatedly without first aligning
the start address, with the result that one word is missed from the
scan every MAX_SCAN_SIZE bytes when __start_ro_after_init is not
aligned.  The following untested patch should fix this.
Alternatively, align __start_ro_after_init in the script.

--- mm/kmemleak.c~	2019-01-17 07:34:38.000000000 +1030
+++ mm/kmemleak.c	2019-12-02 14:33:20.997174278 +1030
@@ -1377,6 +1377,7 @@ static void scan_large_block(void *start
 {
 	void *next;
 
+	start = PTR_ALIGN(start, BYTES_PER_POINTER);
 	while (start < end) {
 		next = min(start + MAX_SCAN_SIZE, end);
 		scan_block(start, next, NULL);

-- 
Alan Modra
Australia Development Lab, IBM