Re: Fwd: Fwd: X stopped working with 5.14 on iBook

Re: Fwd: Fwd: X stopped working with 5.14 on iBook

[Christophe Leroy]

Copied to Christopher M. Riedl <cmr@linux.ibm.com> and linuxppc list.

Le 22/10/2021 à 19:40, Stan Johnson a écrit :
> Hello Christophe and Finn,
> 
> My message to Christopher Riedl bounced:
> 
> <cmr@codefail.de>:
> 554: 5.7.1 <cmr@codefail.de>: 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 <userm57@yahoo.com>
> To: Christopher M. Riedl <cmr@codefail.de>
> CC: Finn Thain <fthain@fastmail.com.au>
> 
> 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 <userm57@yahoo.com>
> To: debian-powerpc@lists.debian.org
> CC: Riccardo Mottola <riccardo.mottola@libero.it>
> 
> On 10/14/21 9:21 PM, Stan Johnson wrote:
>> ...
>> 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)
>> 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 <cmr@codefail.de>
> 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 <cmr@codefail.de>
>      Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>      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(-)
> 

Re: Fwd: Fwd: X stopped working with 5.14 on iBook

[Finn Thain]

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:

> ...
> > 
> > -------- 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 <cmr@codefail.de>
> > CC: Finn Thain <fthain@fastmail.com.au>
> > 
> > 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 <riccardo.mottola@libero.it>
> > 
> > On 10/14/21 9:21 PM, Stan Johnson wrote:
> > > ...
> > > 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)
> > > 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 <cmr@codefail.de>
> > 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 <cmr@codefail.de>
> >      Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> >      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(-)
> > 
> 

Re: Fwd: Fwd: X stopped working with 5.14 on iBook

[Christopher M. Riedl]

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:
>
> > ...
> > > 
> > > -------- 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 <cmr@codefail.de>
> > > CC: Finn Thain <fthain@fastmail.com.au>
> > > 
> > > 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 <riccardo.mottola@libero.it>
> > > 
> > > On 10/14/21 9:21 PM, Stan Johnson wrote:
> > > > ...
> > > > 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)
> > > > 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 <cmr@codefail.de>
> > > 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 <cmr@codefail.de>
> > >      Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> > >      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(-)
> > > 
> > 

Re: Fwd: Fwd: X stopped working with 5.14 on iBook

[Riccardo Mottola]

Hi All,


Christopher M. Riedl wrote:
> 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

Re: Fwd: Fwd: X stopped working with 5.14 on iBook

[Andreas Schwab]

On Nov 02 2021, Finn Thain wrote:

> 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

On my iBook G4, X is working alright with 5.15 and CONFIG_USER_NS=y.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Fwd: Fwd: X stopped working with 5.14 on iBook

[Finn Thain]

On Wed, 3 Nov 2021, Andreas Schwab wrote:

> On Nov 02 2021, Finn Thain wrote:
> 
> > 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
> 
> On my iBook G4, X is working alright with 5.15 and CONFIG_USER_NS=y.
> 

Stan said his Cube has these packages installed:

# dpkg --list | grep Xorg
ii  xserver-xorg-core                      2:1.20.11-1
      powerpc      Xorg X server - core server
ii  xserver-xorg-legacy                    2:1.20.11-1
      powerpc      setuid root Xorg server wrapper

I gather that Riccardo also runs Debian SID.

Perhaps there is some interaction between d3ccc9781560, CONFIG_USER_NS and 
the SUID wrapper...

Does your Xorg installation use --enable-suid-wrapper, Andreas?

Re: Fwd: Fwd: X stopped working with 5.14 on iBook

[Andreas Schwab]

On Nov 04 2021, Finn Thain wrote:

> Does your Xorg installation use --enable-suid-wrapper, Andreas?

Doesn't look like.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Fwd: Fwd: X stopped working with 5.14 on iBook

[Stanley Johnson]

On Wednesday, November 3rd, 2021 at 4:26 PM, Finn Thain <fthain@linux-m68k.org> wrote:

> On Wed, 3 Nov 2021, Andreas Schwab wrote:
>
> > On Nov 02 2021, Finn Thain wrote:
> >
> > > 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
> >
> > On my iBook G4, X is working alright with 5.15 and CONFIG_USER_NS=y.
>
> Stan said his Cube has these packages installed:
>
> dpkg --list | grep Xorg
> =======================
>
> ii xserver-xorg-core 2:1.20.11-1
>
> powerpc Xorg X server - core server
>
> ii xserver-xorg-legacy 2:1.20.11-1
>
> powerpc setuid root Xorg server wrapper
>
> I gather that Riccardo also runs Debian SID.
>
> Perhaps there is some interaction between d3ccc9781560, CONFIG_USER_NS and
>
> the SUID wrapper...
>
> Does your Xorg installation use --enable-suid-wrapper, Andreas?

Hi Andreas,

Does X work for you if you use the current Debian SID installation with their current default kernel? That's how this all started. The problem was eventually isolated via a git bisect and an exhaustive search of kernel options to the identified "bad commit" and the kernel option CONFIG_USER_NS. The kernel just before the bad commit works with or without CONFIG_USER_NS set, but as of the bad commit, X works only with CONFIG_USER_NS not set, at least on my G4 Cube.

Hi Riccardo,

The G3 system I used for testing was a PowerBook Series II Wallstreet, using the same kernel and Xorg versions that I'm using on the Cube. The same test that failed on the Cube worked on the Wallstreet. Of course, this result may not be consistent with other G3 systems. On your iBook G4, if you recompile the kernel (the one that results in an X that doesn't work on your system) and set CONFIG_USER_NS=n, does X then work?

-Stan

Re: Fwd: Fwd: X stopped working with 5.14 on iBook

[Andreas Schwab]

I don't use debian.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Fwd: Fwd: X stopped working with 5.14 on iBook

[Christophe Leroy]

Le 02/11/2021 à 03:20, Finn Thain a écrit :
> 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

Re: Fwd: Fwd: X stopped working with 5.14 on iBook

[Stanley Johnson]

[-- Attachment #1: Type: text/plain, Size: 3586 bytes --]

> 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

[-- Attachment #2: config-5.10.0-8-powerpc.gz --]
[-- Type: application/x-gzip, Size: 46373 bytes --]

Re: Fwd: Fwd: X stopped working with 5.14 on iBook

[Stanley Johnson]

On Thursday, November 4th, 2021 at 10:40 AM, Christophe Leroy <christophe.leroy@csgroup.eu> 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 ?

working on that now..

Re: Fwd: Fwd: X stopped working with 5.14 on iBook

[Finn Thain]

[-- Attachment #1: Type: text/plain, Size: 2887 bytes --]

On Thu, 4 Nov 2021, Christophe Leroy wrote:

> Le 02/11/2021 à 03:20, Finn Thain a écrit :
> > 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)) 

Re: Fwd: Fwd: X stopped working with 5.14 on iBook

[Christophe Leroy]

Le 05/11/2021 à 00:36, Finn Thain a écrit :
> On Thu, 4 Nov 2021, Christophe Leroy wrote:
> 
>> Le 02/11/2021 à 03:20, Finn Thain a écrit :
>>> 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))
> 

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

Re: Fwd: Fwd: X stopped working with 5.14 on iBook

[Segher Boessenkool]

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

Re: Fwd: Fwd: X stopped working with 5.14 on iBook

[Stanley Johnson]

[-- Attachment #1: Type: text/plain, Size: 1631 bytes --]

> ...
> 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

[-- Attachment #2: __get_user_sigset_cast.patch --]
[-- Type: application/octet-stream, Size: 1002 bytes --]

From a6cdd3e9a10d29df38fc6c844517ab28d6961227 Mon Sep 17 00:00:00 2001
From: Christophe Leroy <christophe.leroy@csgroup.eu>
Date: Sat, 6 Nov 2021 10:36:52 +1100
Subject: [PATCH] Re: Fwd: Fwd: X stopped working with 5.14 on iBook

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

diff --git a/arch/powerpc/kernel/signal.h b/arch/powerpc/kernel/signal.h
index 1393876f3814..d4d173a70913 100644
--- a/arch/powerpc/kernel/signal.h
+++ b/arch/powerpc/kernel/signal.h
@@ -23,7 +23,7 @@ static inline int __get_user_sigset(sigset_t *dst, const sigset_t __user *src)
 {
 	BUILD_BUG_ON(sizeof(sigset_t) != sizeof(u64));
 
-	return __get_user(dst->sig[0], (u64 __user *)&src->sig[0]);
+	return __get_user(*(u64*)&dst->sig[0], (u64 __user *)&src->sig[0]);
 }
 
 #ifdef CONFIG_VSX

[-- Attachment #3: __get_user_sigset_cast_5.15.patch --]
[-- Type: application/octet-stream, Size: 1259 bytes --]

From 5f80d4984f62f60a4bea748e8508d1baa171c0a5 Mon Sep 17 00:00:00 2001
From: Christophe Leroy <christophe.leroy@csgroup.eu>
Date: Sat, 6 Nov 2021 10:36:52 +1100
Subject: [PATCH] Fwd: Fwd: X stopped working with 5.14 on iBook

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

diff --git a/arch/powerpc/kernel/signal.h b/arch/powerpc/kernel/signal.h
index 1f07317964e4..aba8a9e751e8 100644
--- a/arch/powerpc/kernel/signal.h
+++ b/arch/powerpc/kernel/signal.h
@@ -23,10 +23,10 @@ static inline int __get_user_sigset(sigset_t *dst, const sigset_t __user *src)
 {
 	BUILD_BUG_ON(sizeof(sigset_t) != sizeof(u64));
 
-	return __get_user(dst->sig[0], (u64 __user *)&src->sig[0]);
+	return __get_user(*(u64*)&dst->sig[0], (u64 __user *)&src->sig[0]);
 }
 #define unsafe_get_user_sigset(dst, src, label) \
-	unsafe_get_user((dst)->sig[0], (u64 __user *)&(src)->sig[0], label)
+	unsafe_get_user(*(u64*)&(dst)->sig[0], (u64 __user *)&(src)->sig[0], label)
 
 #ifdef CONFIG_VSX
 extern unsigned long copy_vsx_to_user(void __user *to,