Re: [RFC v2] MIPS: R5900: Workaround exception NOP execution bug (FLX05)

[Fredrik Noring <noring@nocrew.org>]

Hi Maciej,

>  You could use /dev/mem to inspect exception handlers I suppose, but that 
> would be awkward.  It's mostly useful to access MMIO as I described in the 
> message you were kind enough to dig out from the depths of history.
> 
>  For exception handler examination I suggest using /proc/kcore instead, 
> which gives you access to kernel memory via an artificial ELF image, 
> making this a piece of cake.  Like this for example:
> 
> $ gdb -c /proc/kcore
> [...]
> #0  0x00000000 in ?? ()
> (gdb) set architecture mips:isa32r2
> The target architecture is assumed to be mips:isa32r2
> (gdb) x /32i 0x80000000
> 0x80000000:	lui	k1,0x8483
> 0x80000004:	mfc0	k0,c0_badvaddr
> 0x80000008:	lw	k1,-30560(k1)
> 0x8000000c:	srl	k0,k0,0x1a

This was an interesting exercise. I suspect GDB runs out of memory since

	# gdb -q -c /proc/kcore
	[New process 1]
	Segmentation fault

with

	# dmesg | tail -n3
	do_page_fault(): sending SIGSEGV to gdb for invalid read access from 000000a8
	epc = 00953910 in gdb[400000+6d1000]
	ra  = 009538b8 in gdb[400000+6d1000]

to me looks like GDB does a NULL pointer deference (the PS2 has 32 MiB of
RAM, of which 16 MiB is used for a ramdisk in my setup). GDB once could
handle core files remotely, but this capability is apparently now lost:

https://www.redhat.com/archives/crash-utility/2011-December/msg00019.html

One can get a little further by sharing /proc using v9fs to obtain:

	# mipsel-linux-gdb -q -c /mnt/kcore
	[New process 1]
	Core was generated by `ramdisk_size=16384 crtmode=pal1 video=ps2fb:pal,640x480-32 rd_start=0x8063c000'.
	#0  0x00000000 in ?? ()
	(gdb) set architecture mips:5900
	The target architecture is assumed to be mips:5900
	(gdb) x /32i 0x80000000
	   0x80000000:	Cannot access memory at address 0x80000000

In this case I'm wondering whether kcore contains proper ELF headers. What
is the output of readelf for your kcore? I have this:

	ELF Header:
	  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
	  Class:                             ELF32
	  Data:                              2's complement, little endian
	  Version:                           1 (current)
	  OS/ABI:                            UNIX - System V
	  ABI Version:                       0
	  Type:                              CORE (Core file)
	  Machine:                           MIPS R3000
	  Version:                           0x1
	  Entry point address:               0x0
	  Start of program headers:          52 (bytes into file)
	  Start of section headers:          0 (bytes into file)
	  Flags:                             0x0
	  Size of this header:               52 (bytes)
	  Size of program headers:           32 (bytes)
	  Number of program headers:         3
	  Size of section headers:           0 (bytes)
	  Number of section headers:         0
	  Section header string table index: 0
	
	There are no sections in this file.
	
	There are no sections to group in this file.
	
	Program Headers:
	  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
	  NOTE           0x000094 0x00000000 0x00000000 0x0074c 0x00000     0
	  LOAD           0x40001000 0xc0000000 0xffffffff 0x3f7fe000 0x3f7fe000 RWE 0x1000
	  LOAD           0x001000 0x80000000 0x00000000 0x2000000 0x2000000 RWE 0x1000
	
	There is no dynamic section in this file.
	
	There are no relocations in this file.
	
	The decoding of unwind sections for machine type MIPS R3000 is not currently supported.
	
	No version information found in this file.
	
	Displaying notes found at file offset 0x00000094 with length 0x0000074c:
	  Owner                 Data size	Description
	  CORE                 0x00000100	NT_PRSTATUS (prstatus structure)
	  CORE                 0x00000080	NT_PRPSINFO (prpsinfo structure)
	  CORE                 0x00000590	NT_TASKSTRUCT (task structure)

Returning to the more awkward /dev/mem device, the "bad address" error with
for example

	# xxd -s $(( 0x80000000 )) -l 256 /dev/mem
	xxd: /dev/mem: Bad address

is due to drivers/char/mem.c:valid_phys_addr_range which fails on

	return addr + count <= __pa(high_memory);

since

	0x80000000 + 16 <= 0x2000000

is false for CPHYSADDR(0x82000000) in arch/mips/include/asm/page.h:___pa:

	if (!IS_ENABLED(CONFIG_EVA)) {
		/*
		 * We're using the standard MIPS32 legacy memory map, ie.
		 * the address x is going to be in kseg0 or kseg1. We can
		 * handle either case by masking out the desired bits using
		 * CPHYSADDR.
		 */
		return CPHYSADDR(x);
	}

I noticed that /dev/mem is an exception to this comment just above ___pa:

	/*
	 * __pa()/__va() should be used only during mem init.
	 */

Finally, trying to mmap /dev/mem also fails, because

	/* Does it even fit in phys_addr_t? */                                  
	if (offset >> PAGE_SHIFT != vma->vm_pgoff) {                            

in drivers/char/mem.c:mmap_mem computes

	0x00080000 != 0xfff80000

resulting in -EINVAL. Is this the expected behaviour?

Fredrik