Message ID | 78eef00e-4156-bdbf-cda1-688ae0495414@windriver.com |
---|---|
State | New |
Headers | show |
On Wed, Dec 7, 2016 at 11:18 AM, Bruce Ashfield <bruce.ashfield@windriver.com> wrote: > With the attached patch, I see nothing else that is named in /tmp/ > > If you have the cycles, can you give it a try and let me know ? Yes, I'm giving it a whirl right now. Thanks! -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Wed, Dec 7, 2016 at 1:05 PM, Trevor Woerner <twoerner@gmail.com> wrote: > On Wed, Dec 7, 2016 at 11:18 AM, Bruce Ashfield > <bruce.ashfield@windriver.com> wrote: >> With the attached patch, I see nothing else that is named in /tmp/ >> >> If you have the cycles, can you give it a try and let me know ? > > Yes, I'm giving it a whirl right now. Thanks! That patch looks good, how soon can it land? ;-) I'm sure there's still something in the build that is creating temporary files in /tmp. I'm not sure which process is doing it, I have no reason to suspect it's the kernel tools (in fact I think it happens too early in the build to be the kernel tools), and the tmp files that are created are named with temporary names (e.g. /tmp/tmp.2wavbhTlDU) so they shouldn't interfere with multiple users building on the same machine. Each build appears to create two such temp files that aren't cleaned up at the end of the build. Not a big deal. I don't think it's something new that was introduced recently (but I'd have to do more investigation to verify). -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On 2016-12-07 6:50 PM, Trevor Woerner wrote: > On Wed, Dec 7, 2016 at 1:05 PM, Trevor Woerner <twoerner@gmail.com> wrote: >> On Wed, Dec 7, 2016 at 11:18 AM, Bruce Ashfield >> <bruce.ashfield@windriver.com> wrote: >>> With the attached patch, I see nothing else that is named in /tmp/ >>> >>> If you have the cycles, can you give it a try and let me know ? >> >> Yes, I'm giving it a whirl right now. Thanks! > > That patch looks good, how soon can it land? ;-) For my part, I'll send it first thing tomorrow along with some version bumps to the kernel. > > I'm sure there's still something in the build that is creating > temporary files in /tmp. I'm not sure which process is doing it, I > have no reason to suspect it's the kernel tools (in fact I think it > happens too early in the build to be the kernel tools), and the tmp > files that are created are named with temporary names (e.g. > /tmp/tmp.2wavbhTlDU) so they shouldn't interfere with multiple users > building on the same machine. Each build appears to create two such > temp files that aren't cleaned up at the end of the build. Not a big > deal. I don't think it's something new that was introduced recently > (but I'd have to do more investigation to verify). I noticed one mktemp file leaking when I was fixing the bug at hand today. I made a note to loop back and have a look for where an early exit is skipping clean up. If it is the tools, I'll fix it along with the patch I did today. Bruce > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On 2016-12-07 06:50 PM, Trevor Woerner wrote: > On Wed, Dec 7, 2016 at 1:05 PM, Trevor Woerner <twoerner@gmail.com> wrote: >> On Wed, Dec 7, 2016 at 11:18 AM, Bruce Ashfield >> <bruce.ashfield@windriver.com> wrote: >>> With the attached patch, I see nothing else that is named in /tmp/ >>> >>> If you have the cycles, can you give it a try and let me know ? >> >> Yes, I'm giving it a whirl right now. Thanks! > > That patch looks good, how soon can it land? ;-) > > I'm sure there's still something in the build that is creating > temporary files in /tmp. I'm not sure which process is doing it, I > have no reason to suspect it's the kernel tools (in fact I think it > happens too early in the build to be the kernel tools), and the tmp > files that are created are named with temporary names (e.g. > /tmp/tmp.2wavbhTlDU) so they shouldn't interfere with multiple users > building on the same machine. Each build appears to create two such > temp files that aren't cleaned up at the end of the build. Not a big > deal. I don't think it's something new that was introduced recently > (but I'd have to do more investigation to verify). I did find one mktemp file that wasn't being cleaned up. I fixed it and updated my commit to include that fix. It'll all be out later today with my kernel version bumps + CVE series. Bruce > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
From 707978ff47533c705eac42619988793f07a66b80 Mon Sep 17 00:00:00 2001 From: Bruce Ashfield <bruce.ashfield@windriver.com> Date: Wed, 7 Dec 2016 11:14:34 -0500 Subject: [PATCH] kern-tools: ensure that no shared directories are used We need to avoid using shared/common directories for any files that are part of specific build, since permissions issues in multi user environments will cause issues. Integrating the following commit to solve the issue: scc: move unused patch queue under output dir Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> --- meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb index 0f8a786176f9..3ca6ca22ef20 100644 --- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb +++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb @@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1b DEPENDS = "git-native" -SRCREV = "bd9e1d6c9b0a34ff3e19a06999aaf57ffadfd04c" +SRCREV = "626ceac135fa66277c2fa53197be33cc9d4d7614" PR = "r12" PV = "0.2+git${SRCPV}" -- 2.5.0