Re: Fwd: Fwd: X stopped working with 5.14 on iBook
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
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
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
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
I don't use debian. Andreas. -- Andreas Schwab, sch...@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
On Nov 04 2021, Finn Thain wrote: > Does your Xorg installation use --enable-suid-wrapper, Andreas? Doesn't look like. Andreas. -- Andreas Schwab, sch...@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
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-legacy2: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
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, sch...@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
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
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 > > > CC: Finn Thain > > > > > > 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-powe...@lists.debian.org > > > CC: Riccardo Mottola > > > > > > 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) > > > > 85f3f17b5db2dd9f8a094a0ddc66135afd22] 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 > > > 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 implemen
Re: Fwd: Fwd: X stopped working with 5.14 on iBook
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 > > CC: Finn Thain > > > > 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-powe...@lists.debian.org > > CC: Riccardo Mottola > > > > 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) > > > 85f3f17b5db2dd9f8a094a0ddc66135afd22] 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 > > 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 > > Signed-off-by: Michael Ellerman > > Link: https://lore.kernel.org/r/20210227011259.11992-11-...@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
Re: Fwd: Fwd: X stopped working with 5.14 on iBook
Copied to Christopher M. Riedl and linuxppc list. Le 22/10/2021 à 19:40, Stan Johnson a écrit : Hello Christophe and Finn, My message to Christopher Riedl bounced: : 554: 5.7.1 : 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 To: Christopher M. Riedl CC: Finn Thain 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 user...@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 To: debian-powe...@lists.debian.org CC: Riccardo Mottola 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) 85f3f17b5db2dd9f8a094a0ddc66135afd22] 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 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 Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210227011259.11992-11-...@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(-)
