Copied to Christopher M. Riedl [off-list ref] and linuxppc list.
Le 22/10/2021 à 19:40, Stan Johnson a écrit :
Hello Christophe and Finn,
My message to Christopher Riedl bounced:
[off-list ref]:
554: 5.7.1 [off-list ref]: Relay access denied
I'm not sure how to proceed; thanks for any help.
You should always copy the list, as other people might be interested by
your problem and/or may help you.
Christophe
-Stan
-------- Forwarded Message --------
Subject: Fwd: X stopped working with 5.14 on iBook
Date: Fri, 22 Oct 2021 11:35:21 -0600
From: Stan Johnson <redacted>
To: Christopher M. Riedl <redacted>
CC: Finn Thain <redacted>
Hello Christopher Riedl,
Please see the message below, in which a git bisect identifies a commit
which may have stopped X from working on some PowerPC G4 systems
(specifically the G4 PowerBook and Cube, possibly others).
I'm not sure how to proceed with further tests. If the identified commit
could not have caused the problem, then further testing may be needed.
Please let me know if you need any additional information.
Hopefully your e-mail filter will allow messages from yahoo.com addresses.
thanks for your help
-Stan Johnson
userm57@yahoo.com
-------- Forwarded Message --------
Subject: Re: X stopped working with 5.14 on iBook
Date: Fri, 22 Oct 2021 11:25:14 -0600
From: Stan Johnson <redacted>
To: debian-powerpc@lists.debian.org
CC: Riccardo Mottola <redacted>
On 10/14/21 9:21 PM, Stan Johnson wrote:
quoted
...
Debian's 5.10.0-8 config file works (as expected) with Debian's 5.10.0-8
kernel source.
...
X works with 5.14 using a tuned config file derived from 5.13 testing.
...
Update:
The issue originally reported by Riccardo Mottola was that X wasn't
working on a PowerBook G4 using Debian's default
vmlinux-5.14.0-2-powerpc kernel. I was able to confirm that the X
failure also occurs on a G4 Cube. My G4 Cube has Debian SID,
sysvinit-core, Xfce and wdm installed. To test whether X works, I
disabled wdm, then I log in at the text console and run "startx". When X
fails, the screen goes blank and the backlight stays on; when X works,
the normal desktop comes up.
X works in mainline v5.12 built using a config file based on Debian's
config-5.10.0-8-powerpc.
X fails in mainline v5.13 built using a config file based on Debian's
config-5.10.0-8-powerpc.
With much help and advice from Finn Thain, I was able to run a bisect
using a config file based on Debian's config-5.10.0-8-powerpc, with
v5.12 "good" and v5.13 "bad".
$ git reset --hard
HEAD is now at 62fb9874f5da Linux 5.13
$ git bisect start v5.13
Updating files: 100% (12992/12992), done.
Previous HEAD position was 62fb9874f5da Linux 5.13
HEAD is now at 9f4ad9e425a1 Linux 5.12
$ git bisect bad v5.13
$ git bisect good v5.12
Bisecting: 8739 revisions left to test after this (roughly 13 steps)
quoted
85f3f17b5db2dd9f8a094a0ddc665555135afd22] Merge branch 'md-fixes' of
https://git.kernel.org/pub/scm/linux/kernel/git/song/md into block-5.13
After the bisect, git reports this:
----------
d3ccc9781560af051554017c702631560bdc0811 is the first bad commit
commit d3ccc9781560af051554017c702631560bdc0811
Author: Christopher M. Riedl [off-list ref]
Date: Fri Feb 26 19:12:59 2021 -0600
powerpc/signal: Use __get_user() to copy sigset_t
Usually sigset_t is exactly 8B which is a "trivial" size and does not
warrant using __copy_from_user(). Use __get_user() directly in
anticipation of future work to remove the trivial size optimizations
from __copy_from_user().
The ppc32 implementation of get_sigset_t() previously called
copy_from_user() which, unlike __copy_from_user(), calls access_ok().
Replacing this w/ __get_user() (no access_ok()) is fine here since both
callsites in signal_32.c are preceded by an earlier access_ok().
Signed-off-by: Christopher M. Riedl [off-list ref]
Signed-off-by: Michael Ellerman [off-list ref]
Link: https://lore.kernel.org/r/20210227011259.11992-11-cmr@codefail.de
arch/powerpc/kernel/signal.h | 7 +++++++
arch/powerpc/kernel/signal_32.c | 2 +-
arch/powerpc/kernel/signal_64.c | 4 ++--
3 files changed, 10 insertions(+), 3 deletions(-)
From: Finn Thain <fthain@linux-m68k.org> Date: 2021-11-02 02:26:39
Hi Christopher,
After many builds and tests, Stan and I were able to determine that this
regression only affects builds with CONFIG_USER_NS=y. That is,
d3ccc9781560 + CONFIG_USER_NS=y --> fail
d3ccc9781560 + CONFIG_USER_NS=n --> okay
d3ccc9781560~ + CONFIG_USER_NS=y --> okay
d3ccc9781560~ + CONFIG_USER_NS=n --> okay
Stan also tested a PowerMac G3 system and found that the regression is not
present there. Thus far, only PowerMac G4 systems are known to be affected
(Stan's Cube and Riccardo's PowerBook).
I asked Stan to try v5.15-rc after reverting commit d3ccc9781560.
Unexpectedly, this build had the same issue. So, it appears there are
multiple bad commits that produce this Xorg failure, of which d3ccc9781560
is just the first.
But there's no easy way to identify the other bad commits using bisection.
So I've addressed this message to you. Can you help fix this regression?
Regards,
Finn
On Fri, 22 Oct 2021, Christophe Leroy wrote:
...
quoted
-------- Forwarded Message --------
Subject: Fwd: X stopped working with 5.14 on iBook
Date: Fri, 22 Oct 2021 11:35:21 -0600
From: Stan Johnson
To: Christopher M. Riedl <redacted>
CC: Finn Thain <redacted>
Hello Christopher Riedl,
Please see the message below, in which a git bisect identifies a commit
which may have stopped X from working on some PowerPC G4 systems
(specifically the G4 PowerBook and Cube, possibly others).
I'm not sure how to proceed with further tests. If the identified commit
could not have caused the problem, then further testing may be needed.
Please let me know if you need any additional information.
Hopefully your e-mail filter will allow messages from yahoo.com addresses.
thanks for your help
-Stan Johnson
-------- Forwarded Message --------
Subject: Re: X stopped working with 5.14 on iBook
Date: Fri, 22 Oct 2021 11:25:14 -0600
From: Stan Johnson
To: debian-powerpc@lists.debian.org
CC: Riccardo Mottola <redacted>
On 10/14/21 9:21 PM, Stan Johnson wrote:
quoted
...
Debian's 5.10.0-8 config file works (as expected) with Debian's 5.10.0-8
kernel source.
...
X works with 5.14 using a tuned config file derived from 5.13 testing.
...
Update:
The issue originally reported by Riccardo Mottola was that X wasn't
working on a PowerBook G4 using Debian's default
vmlinux-5.14.0-2-powerpc kernel. I was able to confirm that the X
failure also occurs on a G4 Cube. My G4 Cube has Debian SID,
sysvinit-core, Xfce and wdm installed. To test whether X works, I
disabled wdm, then I log in at the text console and run "startx". When X
fails, the screen goes blank and the backlight stays on; when X works,
the normal desktop comes up.
X works in mainline v5.12 built using a config file based on Debian's
config-5.10.0-8-powerpc.
X fails in mainline v5.13 built using a config file based on Debian's
config-5.10.0-8-powerpc.
With much help and advice from Finn Thain, I was able to run a bisect
using a config file based on Debian's config-5.10.0-8-powerpc, with
v5.12 "good" and v5.13 "bad".
$ git reset --hard
HEAD is now at 62fb9874f5da Linux 5.13
$ git bisect start v5.13
Updating files: 100% (12992/12992), done.
Previous HEAD position was 62fb9874f5da Linux 5.13
HEAD is now at 9f4ad9e425a1 Linux 5.12
$ git bisect bad v5.13
$ git bisect good v5.12
Bisecting: 8739 revisions left to test after this (roughly 13 steps)
quoted
85f3f17b5db2dd9f8a094a0ddc665555135afd22] Merge branch 'md-fixes' of
https://git.kernel.org/pub/scm/linux/kernel/git/song/md into block-5.13
After the bisect, git reports this:
----------
d3ccc9781560af051554017c702631560bdc0811 is the first bad commit
commit d3ccc9781560af051554017c702631560bdc0811
Author: Christopher M. Riedl [off-list ref]
Date: Fri Feb 26 19:12:59 2021 -0600
powerpc/signal: Use __get_user() to copy sigset_t
Usually sigset_t is exactly 8B which is a "trivial" size and does not
warrant using __copy_from_user(). Use __get_user() directly in
anticipation of future work to remove the trivial size optimizations
from __copy_from_user().
The ppc32 implementation of get_sigset_t() previously called
copy_from_user() which, unlike __copy_from_user(), calls access_ok().
Replacing this w/ __get_user() (no access_ok()) is fine here since both
callsites in signal_32.c are preceded by an earlier access_ok().
Signed-off-by: Christopher M. Riedl [off-list ref]
Signed-off-by: Michael Ellerman [off-list ref]
Link: https://lore.kernel.org/r/20210227011259.11992-11-cmr@codefail.de
arch/powerpc/kernel/signal.h | 7 +++++++
arch/powerpc/kernel/signal_32.c | 2 +-
arch/powerpc/kernel/signal_64.c | 4 ++--
3 files changed, 10 insertions(+), 3 deletions(-)
From: Christopher M. Riedl <hidden> Date: 2021-11-02 22:35:41
On Mon Nov 1, 2021 at 9:20 PM CDT, Finn Thain wrote:
Hi Christopher,
After many builds and tests, Stan and I were able to determine that this
regression only affects builds with CONFIG_USER_NS=y. That is,
d3ccc9781560 + CONFIG_USER_NS=y --> fail
d3ccc9781560 + CONFIG_USER_NS=n --> okay
d3ccc9781560~ + CONFIG_USER_NS=y --> okay
d3ccc9781560~ + CONFIG_USER_NS=n --> okay
Stan also tested a PowerMac G3 system and found that the regression is
not
present there. Thus far, only PowerMac G4 systems are known to be
affected
(Stan's Cube and Riccardo's PowerBook).
I asked Stan to try v5.15-rc after reverting commit d3ccc9781560.
Unexpectedly, this build had the same issue. So, it appears there are
multiple bad commits that produce this Xorg failure, of which
d3ccc9781560
is just the first.
But there's no easy way to identify the other bad commits using
bisection.
So I've addressed this message to you. Can you help fix this regression?
Hi,
I switched email addresses a few times since that patch - also I am not
employed at IBM any longer so that @linux.ibm.com email doesn't work
either. In any case, I'll take a look and see if I can figure out what's
going on. I do actually have a PowerBook G4 here (if it can be coaxed to
boot) that could help me root cause this.
Thanks!
Chris R.
Regards,
Finn
On Fri, 22 Oct 2021, Christophe Leroy wrote:
quoted
...
quoted
-------- Forwarded Message --------
Subject: Fwd: X stopped working with 5.14 on iBook
Date: Fri, 22 Oct 2021 11:35:21 -0600
From: Stan Johnson
To: Christopher M. Riedl <redacted>
CC: Finn Thain <redacted>
Hello Christopher Riedl,
Please see the message below, in which a git bisect identifies a commit
which may have stopped X from working on some PowerPC G4 systems
(specifically the G4 PowerBook and Cube, possibly others).
I'm not sure how to proceed with further tests. If the identified commit
could not have caused the problem, then further testing may be needed.
Please let me know if you need any additional information.
Hopefully your e-mail filter will allow messages from yahoo.com addresses.
thanks for your help
-Stan Johnson
-------- Forwarded Message --------
Subject: Re: X stopped working with 5.14 on iBook
Date: Fri, 22 Oct 2021 11:25:14 -0600
From: Stan Johnson
To: debian-powerpc@lists.debian.org
CC: Riccardo Mottola <redacted>
On 10/14/21 9:21 PM, Stan Johnson wrote:
quoted
...
Debian's 5.10.0-8 config file works (as expected) with Debian's 5.10.0-8
kernel source.
...
X works with 5.14 using a tuned config file derived from 5.13 testing.
...
Update:
The issue originally reported by Riccardo Mottola was that X wasn't
working on a PowerBook G4 using Debian's default
vmlinux-5.14.0-2-powerpc kernel. I was able to confirm that the X
failure also occurs on a G4 Cube. My G4 Cube has Debian SID,
sysvinit-core, Xfce and wdm installed. To test whether X works, I
disabled wdm, then I log in at the text console and run "startx". When X
fails, the screen goes blank and the backlight stays on; when X works,
the normal desktop comes up.
X works in mainline v5.12 built using a config file based on Debian's
config-5.10.0-8-powerpc.
X fails in mainline v5.13 built using a config file based on Debian's
config-5.10.0-8-powerpc.
With much help and advice from Finn Thain, I was able to run a bisect
using a config file based on Debian's config-5.10.0-8-powerpc, with
v5.12 "good" and v5.13 "bad".
$ git reset --hard
HEAD is now at 62fb9874f5da Linux 5.13
$ git bisect start v5.13
Updating files: 100% (12992/12992), done.
Previous HEAD position was 62fb9874f5da Linux 5.13
HEAD is now at 9f4ad9e425a1 Linux 5.12
$ git bisect bad v5.13
$ git bisect good v5.12
Bisecting: 8739 revisions left to test after this (roughly 13 steps)
quoted
85f3f17b5db2dd9f8a094a0ddc665555135afd22] Merge branch 'md-fixes' of
https://git.kernel.org/pub/scm/linux/kernel/git/song/md into block-5.13
After the bisect, git reports this:
----------
d3ccc9781560af051554017c702631560bdc0811 is the first bad commit
commit d3ccc9781560af051554017c702631560bdc0811
Author: Christopher M. Riedl [off-list ref]
Date: Fri Feb 26 19:12:59 2021 -0600
powerpc/signal: Use __get_user() to copy sigset_t
Usually sigset_t is exactly 8B which is a "trivial" size and does not
warrant using __copy_from_user(). Use __get_user() directly in
anticipation of future work to remove the trivial size optimizations
from __copy_from_user().
The ppc32 implementation of get_sigset_t() previously called
copy_from_user() which, unlike __copy_from_user(), calls access_ok().
Replacing this w/ __get_user() (no access_ok()) is fine here since both
callsites in signal_32.c are preceded by an earlier access_ok().
Signed-off-by: Christopher M. Riedl [off-list ref]
Signed-off-by: Michael Ellerman [off-list ref]
Link: https://lore.kernel.org/r/20210227011259.11992-11-cmr@codefail.de
arch/powerpc/kernel/signal.h | 7 +++++++
arch/powerpc/kernel/signal_32.c | 2 +-
arch/powerpc/kernel/signal_64.c | 4 ++--
3 files changed, 10 insertions(+), 3 deletions(-)
Stan also tested a PowerMac G3 system and found that the regression is
not
present there. Thus far, only PowerMac G4 systems are known to be
affected
(Stan's Cube and Riccardo's PowerBook).
I actually tested right now on an iBook G3 kernel 5.14.12-1 of 2021-14
from Debian and X does not start on it anyway, with the same behaviour
on the G4.
During the weekend I did test on an iMac G5 and it works.
I don't know how Stan tested - but at least for me issue seems to be
both G3 and G4.
Riccardo
Hi Christopher,
After many builds and tests, Stan and I were able to determine that this
regression only affects builds with CONFIG_USER_NS=y. That is,
d3ccc9781560 + CONFIG_USER_NS=y --> fail
d3ccc9781560 + CONFIG_USER_NS=n --> okay
d3ccc9781560~ + CONFIG_USER_NS=y --> okay
d3ccc9781560~ + CONFIG_USER_NS=n --> okay
Stan also tested a PowerMac G3 system and found that the regression is not
present there. Thus far, only PowerMac G4 systems are known to be affected
(Stan's Cube and Riccardo's PowerBook).
I asked Stan to try v5.15-rc after reverting commit d3ccc9781560.
Unexpectedly, this build had the same issue. So, it appears there are
multiple bad commits that produce this Xorg failure, of which d3ccc9781560
is just the first.
But there's no easy way to identify the other bad commits using bisection.
So I've addressed this message to you. Can you help fix this regression?
I'm wondering if this commit is really the cause of the problem.
Are you using GCC 11 ?
If yes, I think it could be a false positive, fixed by
https://github.com/linuxppc/linux/commit/7315e457d6bc
Can you try with GCC 10 or older ?
Can you cherry pick 7315e457d6bc ("powerpc/uaccess: Fix __get_user()
with CONFIG_CC_HAS_ASM_GOTO_OUTPUT") on top of d3ccc9781560 and see what
happens ?
Thanks
Christophe
From: Stanley Johnson <hidden> Date: 2021-11-04 18:31:10
Andreas Schwab, schwab@linux-m68k.org
On my iBook G4, X is working alright with 5.15 and CONFIG_USER_NS=y.
The attached config file is the same as the current default Debian config file, with the Debian certificate information removed.
To duplicate the X11 error on the G4 Cube:
-----
$ git reset --hard
$ git remote update
$ git checkout v5.15
$ cp ../config-5.10.0-8-powerpc .config
$ ./scripts/config -d DEBUG_INFO
$ ./scripts/config -e LOCALVERSION_AUTO
$ make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- -j4 clean olddefconfig vmlinux modules
$ fgrep CONFIG_USER_NS .config
CONFIG_USER_NS=y
$ strings vmlinux | grep Linux.version
Linux version 5.15.0 (johnson@ThinkPad) (powerpc-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.37) #144 Thu Nov 4 10:17:33 MDT 2021
--> After installing vmlinux and modules, X fails on the G4 Cube.
-----
$ ./scripts/config -d USER_NS
$ make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- -j4 clean olddefconfig vmlinux modules
$ fgrep CONFIG_USER_NS .config
# CONFIG_USER_NS is not set
$ strings vmlinux | grep Linux.version
Linux version 5.15.0 (johnson@ThinkPad) (powerpc-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.37) #145 Thu Nov 4 11:32:02 MDT 2021
--> After installing vmlinux and modules, X works on the G4 Cube.
-----
I get the same results with v5.15-rc7.
-----
On the Cube,
# dmesg | grep -i aty
[ 0.000000] Kernel command line: root=/dev/sda12 ro video=aty128fb:1024x768-32@60
[ 4.057110] aty128fb 0000:00:10.0: enabling device (0086 -> 0087)
[ 4.057515] aty128fb 0000:00:10.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x1111
[ 4.057579] aty128fb: ROM failed to map
[ 4.057597] aty128fb: BIOS not located, guessing timings.
[ 4.057628] aty128fb: Rage128 PF PRO AGP [chip rev 0x1]
[ 4.303733] fb0: ATY Rage128 frame buffer device on Rage128 PF PRO AGP
If you are not able to duplicate the above results on a system with a video card similar to aty128fb, then the problem may be with Xorg or Debian.
While I do have "Xorg X server - core server 2:1.20.11-1" installed on the Cube, I also have other X-related installations that may be relevant (note particularly xserver-xorg-video-radeon):
# dpkg --list | grep xorg
ii xserver-xorg 1:7.7+23 powerpc X.Org X server
ii xserver-xorg-core 2:1.20.11-1 powerpc Xorg X server - core server
ii xserver-xorg-input-all 1:7.7+23 powerpc X.Org X server -- input driver metapackage
ii xserver-xorg-input-libinput 1.1.0-1 powerpc X.Org X server -- libinput input driver
ii xserver-xorg-input-wacom 0.34.99.1-1 powerpc X.Org X server -- Wacom input driver
ii xserver-xorg-legacy 2:1.20.11-1 powerpc setuid root Xorg server wrapper
ii xserver-xorg-video-all 1:7.7+23 powerpc X.Org X server -- output driver metapackage
ii xserver-xorg-video-amdgpu 19.1.0-2 powerpc X.Org X server -- AMDGPU display driver
ii xserver-xorg-video-ati 1:19.1.0-2 powerpc X.Org X server -- AMD/ATI display driver wrapper
ii xserver-xorg-video-fbdev 1:0.5.0-1 powerpc X.Org X server -- fbdev display driver
ii xserver-xorg-video-nouveau 1:1.0.17-1 powerpc X.Org X server -- Nouveau display driver
ii xserver-xorg-video-radeon 1:19.1.0-2 powerpc X.Org X server -- AMD/ATI Radeon display driver
ii xserver-xorg-video-vesa 1:2.5.0-1 powerpc X.Org X server -- VESA display driver
Please let me know if you need any additional information.
thanks
-Stan
From: Stanley Johnson <hidden> Date: 2021-11-04 18:50:12
On Thursday, November 4th, 2021 at 10:40 AM, Christophe Leroy [off-list ref] wrote:
...
Are you using GCC 11 ?
I'm using gcc version 10.2.1 20210110 (Debian 10.2.1-6).
...
Can you cherry pick 7315e457d6bc ("powerpc/uaccess: Fix __get_user()
with CONFIG_CC_HAS_ASM_GOTO_OUTPUT") on top of d3ccc9781560 and see what
happens ?
From: Finn Thain <fthain@linux-m68k.org> Date: 2021-11-04 23:37:10
On Thu, 4 Nov 2021, Christophe Leroy wrote:
Le 02/11/2021 à 03:20, Finn Thain a écrit :
quoted
Hi Christopher,
After many builds and tests, Stan and I were able to determine that this
regression only affects builds with CONFIG_USER_NS=y. That is,
d3ccc9781560 + CONFIG_USER_NS=y --> fail
d3ccc9781560 + CONFIG_USER_NS=n --> okay
d3ccc9781560~ + CONFIG_USER_NS=y --> okay
d3ccc9781560~ + CONFIG_USER_NS=n --> okay
Stan also tested a PowerMac G3 system and found that the regression is not
present there. Thus far, only PowerMac G4 systems are known to be affected
(Stan's Cube and Riccardo's PowerBook).
I asked Stan to try v5.15-rc after reverting commit d3ccc9781560.
Unexpectedly, this build had the same issue. So, it appears there are
multiple bad commits that produce this Xorg failure, of which d3ccc9781560
is just the first.
But there's no easy way to identify the other bad commits using bisection.
So I've addressed this message to you. Can you help fix this regression?
I'm wondering if this commit is really the cause of the problem.
Are you using GCC 11 ?
If yes, I think it could be a false positive, fixed by
https://github.com/linuxppc/linux/commit/7315e457d6bc
Can you try with GCC 10 or older ?
AFAIK, all of Stan's builds were made with gcc 10.
Can you cherry pick 7315e457d6bc ("powerpc/uaccess: Fix __get_user() with
CONFIG_CC_HAS_ASM_GOTO_OUTPUT") on top of d3ccc9781560 and see what happens ?
$ git checkout d3ccc9781560
$ git cherry-pick 7315e457d6bc
Auto-merging arch/powerpc/include/asm/uaccess.h
CONFLICT (content): Merge conflict in arch/powerpc/include/asm/uaccess.h
error: could not apply 7315e457d6bc... powerpc/uaccess: Fix __get_user() with CONFIG_CC_HAS_ASM_GOTO_OUTPUT
There is no __get_user_asm2_goto in this tree, and __get_user_asm2 already
has the "=&r" constraint:
#define __get_user_asm2(x, addr, err) \
__asm__ __volatile__( \
"1: lwz%X2 %1, %2\n" \
"2: lwz%X2 %L1, %L2\n" \
"3:\n" \
".section .fixup,\"ax\"\n" \
"4: li %0,%3\n" \
" li %1,0\n" \
" li %1+1,0\n" \
" b 3b\n" \
".previous\n" \
EX_TABLE(1b, 4b) \
EX_TABLE(2b, 4b) \
: "=r" (err), "=&r" (x) \
: "m" (*addr), "i" (-EFAULT), "0" (err))
Hi Christopher,
After many builds and tests, Stan and I were able to determine that this
regression only affects builds with CONFIG_USER_NS=y. That is,
d3ccc9781560 + CONFIG_USER_NS=y --> fail
d3ccc9781560 + CONFIG_USER_NS=n --> okay
d3ccc9781560~ + CONFIG_USER_NS=y --> okay
d3ccc9781560~ + CONFIG_USER_NS=n --> okay
Stan also tested a PowerMac G3 system and found that the regression is not
present there. Thus far, only PowerMac G4 systems are known to be affected
(Stan's Cube and Riccardo's PowerBook).
I asked Stan to try v5.15-rc after reverting commit d3ccc9781560.
Unexpectedly, this build had the same issue. So, it appears there are
multiple bad commits that produce this Xorg failure, of which d3ccc9781560
is just the first.
But there's no easy way to identify the other bad commits using bisection.
So I've addressed this message to you. Can you help fix this regression?
I'm wondering if this commit is really the cause of the problem.
Are you using GCC 11 ?
If yes, I think it could be a false positive, fixed by
https://github.com/linuxppc/linux/commit/7315e457d6bc
Can you try with GCC 10 or older ?
AFAIK, all of Stan's builds were made with gcc 10.
quoted
Can you cherry pick 7315e457d6bc ("powerpc/uaccess: Fix __get_user() with
CONFIG_CC_HAS_ASM_GOTO_OUTPUT") on top of d3ccc9781560 and see what happens ?
$ git checkout d3ccc9781560
$ git cherry-pick 7315e457d6bc
Auto-merging arch/powerpc/include/asm/uaccess.h
CONFLICT (content): Merge conflict in arch/powerpc/include/asm/uaccess.h
error: could not apply 7315e457d6bc... powerpc/uaccess: Fix __get_user() with CONFIG_CC_HAS_ASM_GOTO_OUTPUT
There is no __get_user_asm2_goto in this tree, and __get_user_asm2 already
has the "=&r" constraint:
#define __get_user_asm2(x, addr, err) \
__asm__ __volatile__( \
"1: lwz%X2 %1, %2\n" \
"2: lwz%X2 %L1, %L2\n" \
"3:\n" \
".section .fixup,\"ax\"\n" \
"4: li %0,%3\n" \
" li %1,0\n" \
" li %1+1,0\n" \
" b 3b\n" \
".previous\n" \
EX_TABLE(1b, 4b) \
EX_TABLE(2b, 4b) \
: "=r" (err), "=&r" (x) \
: "m" (*addr), "i" (-EFAULT), "0" (err))
You are right, __get_user_asm2_goto() was added later.
I think I found the issue.
__get_user_sigset() is wrong for 32 bits.
Could you change its content to return __get_user(*(u64*)&dst->sig[0],
(u64 __user *)&src->sig[0]);
If it works, for the mainline also change unsafe_get_user_sigset()
Christophe
On Fri, Nov 05, 2021 at 10:36:18AM +1100, Finn Thain wrote:
There is no __get_user_asm2_goto in this tree, and __get_user_asm2 already
has the "=&r" constraint:
#define __get_user_asm2(x, addr, err) \
__asm__ __volatile__( \
"1: lwz%X2 %1, %2\n" \
"2: lwz%X2 %L1, %L2\n" \
"3:\n" \
".section .fixup,\"ax\"\n" \
"4: li %0,%3\n" \
" li %1,0\n" \
" li %1+1,0\n" \
" b 3b\n" \
".previous\n" \
EX_TABLE(1b, 4b) \
EX_TABLE(2b, 4b) \
: "=r" (err), "=&r" (x) \
: "m" (*addr), "i" (-EFAULT), "0" (err))
operand 0 needs an earlyclobber as well, in principle. But there is
nothing left it can be tied to, so this won't change generated code.
What is operand 4 about? It isn't used?
The "%1+1" can be written %L1 btw (it means exactly the same thing, but
work on more configs).
Segher
From: Stanley Johnson <hidden> Date: 2021-11-06 01:23:01
...
I think I found the issue.
__get_user_sigset() is wrong for 32 bits.
Could you change its content to return __get_user((u64)&dst->sig[0],
(u64 __user *)&src->sig[0]);
If it works, for the mainline also change unsafe_get_user_sigset()
Christophe
Christophe,
Using the attached patches and git commands provided by Finn (thanks!), here are the results:
$ git reset --hard
$ git checkout d3ccc9781560
$ git am ../__get_user_sigset_cast.patch
$ cp ../dot-config-pmac-5.12.0-rc3-00034-gd3ccc9781560-USER_NS .config
$ make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- -j4 clean olddefconfig vmlinux
$ grep USER_NS .config
CONFIG_USER_NS=y
$ strings vmlinux | grep Linux.version
Linux version 5.12.0-rc3-pmac-00035-g77e46218520e (johnson@ThinkPad) (powerpc-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.37) #146 SMP Fri Nov 5 18:57:46 MDT 2021
With this kernel, X works.
Trying mainline:
$ git reset --hard
$ git checkout v5.15
$ git am ../__get_user_sigset_cast_5.15.patch
$ cp ../dot-config-powermac-5.14 .config
$ ./scripts/config -e USER_NS
$ make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- -j4 clean olddefconfig vmlinux
$ grep USER_NS .config
CONFIG_USER_NS=y
$ strings vmlinux | grep Linux.version
Linux version 5.15.0-pmac-00001-gbc0bc813b6ac (johnson@ThinkPad) (powerpc-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.37) #147 SMP Fri Nov 5 19:17:01 MDT 2021
With this kernel, X also works.
So it appears that your change has fixed the problem, at least on the G4 Cube; thanks!
-Stan