kernel 5.4.3, arm: crash: system.map and dump do not match! (with fix)

[mthenault]

Hi, I have a problem with kernel 5.4 on arm. crash is invoked like this: ./crash vmlinux system.map dump

I get the following result:

kernel 5.4: DBG: WARNING: invalid linux_banner pointer: 756e694c
DBG: crash: system.map and dump do not match!

Here are my observations:

cat system.map | grep linux_banner
c0c00084 D linux_banner

kernel.c:

	if (!(sp = symbol_search("linux_banner")))  // 1. struct syment sp gets filled here
		error(FATAL, "linux_banner symbol does not exist?\n");
	else if ((sp->type == 'R') || (sp->type == 'r') ||
		 (machine_type("ARM") && sp->type == 'T') ||
		 (machine_type("ARM64")))
		linux_banner = symbol_value("linux_banner");   // 2. we don't enter here because sp->type == 'D'
	else                         
		get_symbol_data("linux_banner", sizeof(ulong), &linux_banner); // 3. This doesn't work and gives a wrong address		

With gdb debugging I can see that the struct syment is fine address-wise:

(gdb) print sp->type
$2 = 68 'D'
(gdb) print sp->name
$3 = 0xf73de297 "linux_banner"
(gdb) print sp->value
$4 = 3233808516 (note: c0c00084 hex)

sp->type is equal to 'D' this prevents us to enter the else if even though calling symbol_value("linux_banner"); would be fine:

ulong
symbol_value(char *symbol)
{
        struct syment *sp;

        if (!(sp = symbol_search(symbol))) // calls symbol_search again
                error(FATAL, "cannot resolve \"%s\"\n", symbol);

        return(sp->value);  // correct value (see gdb output)
}

I fixed this locally by adding sp->type == 'D' in the else if condition.

What does 'D' mean in struct syment type ? Is this a bug ? If yes I can submit a patch.

[bhupesh-sharma]

Hello,

On Thu, Sep 10, 2020 at 5:52 PM mthenault [email protected] wrote:

Hi, I have a problem with kernel 5.4 on arm32. crash is invoked like this: ./crash vmlinux system.map dump

I get the following result:

kernel 5.4: DBG: WARNING: invalid linux_banner pointer: 756e694c DBG: crash: system.map and dump do not match!

Here are my observations:

cat system.map | grep linux_banner c0c00084 D linux_banner

kernel.c:

if (!(sp = symbol_search("linux_banner"))) // => struct syment sp gets filled here error(FATAL, "linux_banner symbol does not exist?\n"); else if ((sp->type == 'R') || (sp->type == 'r') || (machine_type("ARM") && sp->type == 'T') || (machine_type("ARM64"))) linux_banner = symbol_value("linux_banner"); // we don't enter here because sp->type == 'D' else get_symbol_data("linux_banner", sizeof(ulong), &linux_banner); // This doesn't work and gives a wrong address

with gdb I can see that the struct syment is fine adress wise:

(gdb) print sp->type $2 = 68 'D' (gdb) print sp->name $3 = 0xf73de297 "linux_banner" (gdb) print sp->value $4 = 3233808516 (note: c0c00084 hex)

sp->type is equal to 'D' this prevents us to enter the first else if even though calling symbol_value("linux_banner"); would be fine:

ulong symbol_value(char *symbol) { struct syment *sp;

    if (!(sp = symbol_search(symbol))) // calls symbol_search again
            error(FATAL, "cannot resolve \"%s\"\n", symbol);

    return(sp->value);  // returns value which is correct (see gdb output)

}

I fixed this locally by adding sp->type == 'D' in the else if condition.

What does 'D' mean in struct syment type ? Is this a bug ? If yes I can submit a patch.

This is very strange - normally you would get a 'R', 'r' or 'T' here instead of a 'D".

For example of my arm64 machine it is a 'R':

cat /boot/System.map-5.9.0-rc3+ | grep linux_banner

ffff800010a90140 R linux_banner

I don't have an arm32 setup available with me right now, so I have requested one on loan, in the meanwhile can you please share the output of '#crash -d31 vmlinux system.mpa dump', so that we can see what linux_banner info (if any) is printed by the crash tool there.

Thanks, Bhupesh

[mthenault]

ok, here is the output output.txt

[k-hagio]

Thanks for your report.

What does 'D' mean in struct syment type ?

I think this description in the man page of nm command is it:

           "D"
           "d" The symbol is in the initialized data section.

Is this a bug ?

It would be depending on why its type is 'D' on your arm32 machine. If it is due to an upstream kernel patch or a configuration and it can happen commonly, then crash should support it.

@bhupesh-sharma Does your arm32 system have the same type 'D'?