On Thu, Feb 11, 2016 at 02:58:55PM +0000, Maciej W. Rozycki wrote: > Date: Thu, 11 Feb 2016 14:58:55 +0000 > From: "Maciej W. Rozycki" <macro@xxxxxxxxxx> > To: Ralf Baechle <ralf@xxxxxxxxxxxxxx> > CC: Daniel Wagner <daniel.wagner@xxxxxxxxxxxx>, > linux-kernel@xxxxxxxxxxxxxxx, linux-mips@xxxxxxxxxxxxxx > Subject: Re: [PATCH v4 2/2] mips: Differentiate between 32 and 64 bit ELF > header > Content-Type: text/plain; charset="ISO-8859-7" > > On Thu, 11 Feb 2016, Maciej W. Rozycki wrote: > > > > > Signed-off-by: Daniel Wagner <daniel.wagner@xxxxxxxxxxxx> > > > > Suggested-by: Maciej W. Rozycki <macro@xxxxxxxxxx> > > > > Reviewed-by: Maciej W. Rozycki <macro@xxxxxxxxxx> > > > > Reported-by: Fengguang Wu <fengguang.wu@xxxxxxxxx> > > > > > > Thanks, applied. > > > > > > I'm getting a less spectacular warning from gcc 5.2: > > > > > > CC fs/proc/vmcore.o > > > fs/proc/vmcore.c: In function ‘parse_crash_elf64_headers’: > > > fs/proc/vmcore.c:939:47: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types] > > > > Yes, the temporaries still need to have their pointed types changed, to > > `Elf32_Ehdr' and `Elf64_Ehdr' respectively, as in the original change. > > > > I had it mentioned in a WIP version of my review (stating that it would > > verify that the correct type is used by the caller), but then deleted that > > part inadvertently, sigh. > > Hold on, I was right in dropping it actually. > > With your v4 change in place all `parse_crash_elf64_headers' is supposed > to call is `mips_elf_check_machine' and that doesn't make any > intialisations, it just dereferences the pointer passed once. This error > does not make any sense to me and line 939 isn't even in > `parse_crash_elf64_headers', which starts at line 999, it's in > `process_ptload_program_headers_elf32'. > > So Ralf, what tree are you using that is off from LMO/Linus by 60 lines? That was 3.16, the oldest version affected. But I'm getting the same messages with different line numbers on more recent kernels including the master branch. Ralf
