Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH v13 00/10] powerpc: Switch to CONFIG_THREAD_INFO_IN_TASK
To:     Michael Ellerman <mpe@ellerman.id.au>,
        Benjamin Herrenschmidt <benh@kernel.crashing.org>,
        Paul Mackerras <paulus@samba.org>,
        Nicholas Piggin <npiggin@gmail.com>,
        Mike Rapoport <rppt@linux.ibm.com>
Cc:     linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
References: <cover.1547195976.git.christophe.leroy@c-s.fr>
 <87zhrx2bf1.fsf@concordia.ellerman.id.au>
From:   Christophe Leroy <christophe.leroy@c-s.fr>
Message-ID: <07e60b5a-611c-9863-f300-68a4f9ad2efd@c-s.fr>
Date:   Tue, 22 Jan 2019 20:42:12 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <87zhrx2bf1.fsf@concordia.ellerman.id.au>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


Le 19/01/2019 à 11:23, Michael Ellerman a écrit :
> Christophe Leroy <christophe.leroy@c-s.fr> writes:
> 
>> The purpose of this serie is to activate CONFIG_THREAD_INFO_IN_TASK which
>> moves the thread_info into task_struct.
>>
>> Moving thread_info into task_struct has the following advantages:
>> - It protects thread_info from corruption in the case of stack
>> overflows.
>> - Its address is harder to determine if stack addresses are
>> leaked, making a number of attacks more difficult.
>>
>> Changes since v12:
>>   - Patch 1: Taken comment from Mike (re-introduced the 'panic' in case memblock allocation fails in setup_64.c
>>   - Patch 1: Added alloc_stack() function in setup_32.c to also panic in case of allocation failure.
> 
> Hi Christophe,
> 
> I can't get this series to boot on qemu mac99. I'm getting eg:
> 
> [    0.981514] NFS: Registering the id_resolver key type
> [    0.981752] Key type id_resolver registered
> [    0.981868] Key type id_legacy registered
> [    0.995711] Unrecoverable exception 0 at 0 (msr=0)
> [    0.996091] Oops: Unrecoverable exception, sig: 6 [#1]
> [    0.996314] BE PAGE_SIZE=4K MMU=Hash PowerMac
> [    0.996617] Modules linked in:
> [    0.996869] CPU: 0 PID: 416 Comm: modprobe Not tainted 5.0.0-rc2-gcc-7.3.0-00043-g53f2de798792 #342
> [    0.997138] NIP:  00000000 LR: 00000000 CTR: 00000000
> [    0.997309] REGS: ef237f50 TRAP: 0000   Not tainted  (5.0.0-rc2-gcc-7.3.0-00043-g53f2de798792)
> [    0.997508] MSR:  00000000 <>  CR: 00000000  XER: 00000000
> [    0.997712]
> [    0.997712] GPR00: 00000000 ef238000 00000000 00000000 00000000 00000000 00000000 00000000
> [    0.997712] GPR08: 00000000 00000000 00000000 00000000 00000000 00000000 c006477c ef13d8c0
> [    0.997712] GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [    0.997712] GPR24: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [    0.998671] NIP [00000000]   (null)
> [    0.998774] LR [00000000]   (null)
> [    0.998895] Call Trace:
> [    0.999030] Instruction dump:
> [    0.999320] XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
> [    0.999546] XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX 60000000 XXXXXXXX XXXXXXXX XXXXXXXX
> [    1.000023] ---[ end trace 925ea3419844fe68 ]---

No such issue on my side. Do you have a ramdisk with anythink special or 
a special config ? I see your kernel is modprobing something, know what 
it is ?

Especially, what is the amount of memory in your config ? On my side 
there is 128M:

Memory: 120292K/131072K available (6116K kernel code, 572K rwdata, 2036K 
rodata,
  340K init, 191K bss, 10780K reserved, 0K cma-reserved, 0K highmem)
Kernel virtual memory layout:
   * 0xfffcf000..0xfffff000  : fixmap
   * 0xff800000..0xffc00000  : highmem PTEs
   * 0xfef36000..0xff800000  : early ioremap
   * 0xc9000000..0xfef36000  : vmalloc & ioremap

This means the addresses in which your kernel faults are in vmalloc 
area. It's not normal I believe, is it ?

On my side it gives the following on qemu mac99 (I have no disk).

[...]
Initialise system trusted keyrings
workingset: timestamp_bits=30 max_order=15 bucket_order=0
NFS: Registering the id_resolver key type
Key type id_resolver registered
Key type id_legacy registered
Key type asymmetric registered
Asymmetric key parser 'x509' registered
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler mq-deadline registered
io scheduler kyber registered
Using unsupported 800x600 (null) at 81000000, depth=32, pitch=3200
Console: switching to colour frame buffer device 100x37
fb0: Open Firmware frame buffer device on /pci@f2000000/QEMU,VGA@e
Generic non-volatile memory driver v1.1
brd: module loaded
loop: module loaded
MacIO PCI driver attached to Keylargo chipset
Macintosh Cuda and Egret driver.
mesh: configured for synchronous 5 MB/s
st: Version 20160209, fixed bufsize 32768, s/g segs 256
Detected ADB keyboard, type ANSI.
input: ADB keyboard as /devices/virtual/input/input0
random: fast init done
input: ADB mouse as /devices/virtual/input/input1
pata-macio 0.00020000:ata-3: Activating pata-macio chipset KeyLargo 
ATA-3, Apple
  bus ID 0
scsi host0: pata_macio
ata1: PATA max MWDMA2 irq 16
pata-macio 0.00021000:ata-3: Activating pata-macio chipset KeyLargo 
ATA-3, Apple
  bus ID 1
scsi host1: pata_macio
ata2: PATA max MWDMA2 irq 18
pcnet32: pcnet32.c:v1.35 21.Apr.2008 tsbogend@alpha.franken.de
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci-pci: OHCI PCI platform driver
ohci-pci 0000:00:0d.0: OHCI PCI host controller
ohci-pci 0000:00:0d.0: new USB bus registered, assigned bus number 1
ohci-pci 0000:00:0d.0: irq 28, io mem 0x80080000
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
usbcore: registered new interface driver appletouch
rtc-generic rtc-generic: registered as rtc0
APM Battery Driver
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
oprofile: using timer interrupt.
Initializing XFRM netlink socket
NET: Registered protocol family 17
NET: Registered protocol family 15
Key type dns_resolver registered
drmem: No dynamic reconfiguration memory found
Loading compiled-in X.509 certificates
rtc-generic rtc-generic: setting system clock to 2019-01-22T19:35:11 UTC 
(154818
5711)
Warning: unable to open an initial console.
ata2.00: ATAPI: QEMU DVD-ROM, 2.5+, max UDMA/100
scsi 1:0:0:0: CD-ROM            QEMU     QEMU DVD-ROM     2.5+ PQ: 0 ANSI: 5
sr 1:0:0:0: [sr0] scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray
cdrom: Uniform CD-ROM driver Revision: 3.20
sr 1:0:0:0: Attached scsi generic sg0 type 5
VFS: Cannot open root device "(null)" or unknown-block(8,1): error -6
Please append a correct "root=" boot option; here are the available 
partitions:
0100            4096 ram0
  (driver?)
0101            4096 ram1
  (driver?)
0102            4096 ram2
  (driver?)
0103            4096 ram3
  (driver?)
0104            4096 ram4
  (driver?)
0105            4096 ram5
  (driver?)
0106            4096 ram6
  (driver?)
0107            4096 ram7
  (driver?)
0108            4096 ram8
  (driver?)
0109            4096 ram9
  (driver?)
010a            4096 ram10
  (driver?)
010b            4096 ram11
  (driver?)
010c            4096 ram12
  (driver?)
010d            4096 ram13
  (driver?)
010e            4096 ram14
  (driver?)
010f            4096 ram15
  (driver?)
0b00         1048575 sr0
  driver: sr
Kernel panic - not syncing: VFS: Unable to mount root fs on 
unknown-block(8,1)
CPU: 0 PID: 1 Comm: swapper Not tainted 5.0.0-rc3+ #790
Call Trace:
[c7837e60] [c003dcf0] panic+0x12c/0x2e8 (unreliable)
[c7837ec0] [c07fc824] mount_block_root+0x1fc/0x2c0
[c7837f10] [c07fcc54] prepare_namespace+0x198/0x1d4
[c7837f30] [c000539c] kernel_init+0x18/0x10c
[c7837f40] [c00131d8] ret_from_kernel_thread+0x14/0x1c
Rebooting in 180 seconds..

Christophe