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

Richard Purdie richard.purdie at linuxfoundation.org
Sat Feb 29 10:12:36 UTC 2020


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.

Cheers,

Richard





More information about the Openembedded-core mailing list