Fwd: Fwd: X stopped working with 5.14 on iBook

Tue Nov 2 13:20:21 AEDT 2021

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 at codefail.de>
> > CC: Finn Thain <fthain at 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 at lists.debian.org
> > CC: Riccardo Mottola <riccardo.mottola at 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 at 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 at codefail.de>
> >      Signed-off-by: Michael Ellerman <mpe at 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(-)
> > 
> 