[OE-core] [PATCH v3] make: 4.2.1 -> 4.3

[Richard Purdie]

On Sat, 2020-02-29 at 10:12 +0000, Richard Purdie wrote:
> Hi Victor,
> 
> On Sat, 2020-02-29 at 07:55 +0000, Victor Kamensky (kamensky) wrote:
> > I was able to reproduce and debugged the mips new make issue.
> > Workaround patch attached.
> > 
> > In summary: kernelmodule.KernelModuleTest.test_kernel_module
> > fails with 'fatal error: opening dependency file
> > scripts/basic/.fixdep.d: Permission denied'
> > 
> > New make-4.3 started using posix_spawn glibc call,
> > that happens to be broken on mips. On mips during posix_spawn call
> > __spawni_child function that is executed after clone makes
> > setresuid call with spurious/wrong value of ruid. Instead of -1
> > it passes 127, effectively switching real user id since test
> > runs under root. Subsequent gcc runs under wrong ruid and it
> > fails to write into /usr/src/kernel/scripts/basic directory.
> > 
> > __spawni_child uses direct system call invocation for setresuid
> > rather calling glibc function. And there is wrong code generation
> > issue somewhere in inline assembly for direct system call and/or
> > way how compiler processes it. I did not dig into it yet, it
> > looks as quite hard problem and needs more time.
> > 
> > For now I've made workaround patch that just through configure
> > ac_cv_func_posix_spawn=no parameter tells make configure not to use
> > posix_spawn on mips.
> > 
> > I will also send suggested patch through 'git send-mail'
> > 
> > Tested workaround on qemumips64, did not have time for
> > qemumips full test, verified build only and made sure that
> > posix_spawn is not used. But I believe it is the same issue.
> 
> Thanks for the quick turnaround on this, sounds like good progress on
> a
> workaround! It does massively help with the preparation for 3.1 and
> is
> much appreciated.
> 
> I've put the patch in for testing. It sounds like there may be an
> upstream glibc patch which might be the fix of the underlying issue.
> I'll probably look to merge the workaround and then we could look at
> the glibc upgrade next.
> 
> I'll report back on how the testing goes.

Looks good, thanks!

I'll merge with a comment about the issue and likely fix when we can
drop it.

Cheers,

Richard