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 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
