[PATCH v3 31/41] powerpc/32: Dismantle EXC_XFER_STD/LITE/TEMPLATE

[Stan Johnson]

On 7/31/21 7:21 PM, Finn Thain wrote:
> On Sat, 31 Jul 2021, Christophe Leroy wrote:
> 
>>>
>>> Stan Johnson contacted me about a regression in mainline that he 
>>> observed on his G3 Powerbooks. Using 'git bisect' we determined that 
>>> this patch was the cause of the regression, i.e. commit 4c0104a83fc3 
>>> ("powerpc/32: Dismantle EXC_XFER_STD/LITE/TEMPLATE").
>>>
>>> When testing 4c0104a83fc and all subsequent builds, various user 
>>> processes were liable to segfault. Here is the console log that Stan 
>>> provided:
>>
>> Hi, i will be able to look at that more in details next week, however I 
>> have a few preliminary qurstions.
>>
>> Can you reliabily reproduce the problem with the said commit, and can 
>> you reliabily run without problem with the parent commit ? 
> 
> Yes and yes. (I already asked Stan to establish those things before I 
> contacted the list.)
> 
>> I'm asking because at first look that commit doesn't bring any 
>> functionnal change.
>>
>> Coukd you provide your .config ?
>>
> 
> Please see attached. My understanding is that all of Stan's builds were 
> performed like this:
> 
> $ cp ../dot-config-powermac-5.13 .config
> $ make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- -j4 clean olddefconfig vmlinux

Yes, that's right.

> 
>> Could you try without CONFIG_VMAP_STACK
>>
> 
> Stan, would you please test the following build:
> 
> $ git checkout v5.13
> $ cp ../dot-config-powermac-5.13 .config
> $ scripts/config -d CONFIG_VMAP_STACK
> $ make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- -j4 clean olddefconfig vmlinux
> 
Please see the attached serial console log (four boots):
1) v5.13-mac, CONFIG_VMAP_STACK=y, mem=512M (fails)
2) v5.13-mac, CONFIG_VMAP_STACK=y, mem=384M (works)
3) v5.13-mac, CONFIG_VMAP_STACK=n, mem=512M (works)
4) v5.13-mac, CONFIG_VMAP_STACK=n, mem=384M (works)

My apologies if the extra boots were not needed (due to the time
difference, I'm trying to anticipate future requests).

Cutting and pasting Finn's commands above builds a new kernel
(5.13.0-pmac) with the following in .config:

$ fgrep VMAP .config
CONFIG_HAVE_ARCH_VMAP_STACK=y
CONFIG_VMAP_STACK=y

I'm not sure what "scripts/config -d CONFIG_VMAP_STACK" does, since
"CONFIG_VMAP_STACK=y" is in "../dot-config-powermac-5.13 .config".

1) I booted the resulting kernel on a 512M Wallstreet (WS-1) with its
default memory setting (i.e. not specifying a mem= parameter in BootX);
that boot proceed to a login prompt (serial console and fb console wdm
prompt). There were multiple errors, and the X login screen hung.

2) Repeating 1) but with "mem=384M" passed to the kernel, everything
worked as expected (X worked, no errors logged).

Next, I edited .config and changed "CONFIG_VMAP_STACK=y" to
"CONFIG_VMAP_STACK=n", then I ran:
"make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- -j4 clean
olddefconfig vmlinux"

The resulting .config does not set CONFIG_VMAP_STACK:
$ fgrep VMAP .config
CONFIG_HAVE_ARCH_VMAP_STACK=y
# CONFIG_VMAP_STACK is not set

3) Same as 1 (512M) but with CONFIG_VMAP_STACK not set in v5.13.
Everything works (no problems with X, no errors logged).

4) Same as 2 (384M) but with CONFIG_VMAP_STACK not set in v5.13.
Everything works (no problems with X, no errors logged).

Please let me know if you need anything else.

thanks for investigating this problem

-Stan Johnson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WS-1_serial_console.txt.xz
Type: application/octet-stream
Size: 10428 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20210801/ee682f4d/attachment-0001.obj>