From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Sam Liddicott <sam@liddicott.com>
Cc: bitbake-devel@lists.openembedded.org, matt.cowell@nokia.com
Subject: Re: [bitbake-devel] pseudo abort with req '/proc/self/fd/3'
Date: Sun, 07 Apr 2024 11:04:44 +0100 [thread overview]
Message-ID: <9ce5ba6c0ea52f2c636874c88051d216fd2f2c9f.camel@linuxfoundation.org> (raw)
In-Reply-To: <CAOj-5WCj04cnjeNrkfF2igx6a5nxERTFhKhd02q_NTd97AzYwA@mail.gmail.com>
On Sat, 2024-04-06 at 12:03 +0100, Sam Liddicott wrote:
> This is becoming a problem for quite a few of our developers who are
> able to proceed with PSEUDO_IGNORE_PATHS:append=",/proc,/dev,/sys"
>
> I understand that PSEUDO_IGNORE_PATHS refers to the host file system
> paths, not the pseudo file system paths so how does excluding these
> cause a problem?
>
> I should add that we are also using the patch from Matt Cowell in
> 2019:
>
> > From cb69146d18382f272e347338cfc5a8930f693ed6 Mon Sep 17 00:00:00
> > 2001
> > From: Matt Cowell <matt.cowell@nokia.com>
> > Date: Wed, 17 Apr 2019 15:51:07 -0500
> > Subject: [PATCH] pseudo_fix_path: do not expand symlinks in /proc
>
> otherwise our recipes fail on access to /dev/fd/3 and /dev/stdout and
> "files" of that nature, due to pseudo failing to properly resolve
> symlinks, as discussed
> here: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13288#c14
>
> In any case, the general problem exists of how to deal with clashing
> inodes. Perhaps we are more prone to this issue because we are using
> user namespaces and mount namespaces to bind mount the build output
> dir so that it always appears at the same path, so that we get better
> SSTATE caching, maybe this makes inode clashing more likely.
This get a bit tricky as you're using a patch we weren't able to merge
because of issues, then you're running into issues and needing to add
other changes on top. Your workflow sounds to be one the project isn't
actively using right now. I can't tell if the original patch required
the change, whether it's specific to your workflow or exactly which
behaviour we're really trying to fix, or if it is really broken.
I still suspect that some code may open via /proc/self/fd/X and then do
chown() or similar on it and we'd then miss data we need. /sys and /dev
are arguable and likely less of an issue.
I haven't really used user namespaces/mounts so I don't know what the
inode situation is there. Do they persist consistently between
executions of bitbake or between processes? I suspect you're right and
this is related to that, however since we don't use that and we don't
have any examples of that code, it is hard to say.
If the problem is different filesystems clashing, we may need to be
more careful about storing filesystem/inode pairs. The hard part is
finding an ID for the filesystem that will be consistent as some IDs we
could use would change at reboot. That obviously will have a
performance impact.
Cheers,
Richard
prev parent reply other threads:[~2024-04-07 10:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <17B810A24531435C.23432@lists.openembedded.org>
2024-02-28 22:56 ` [bitbake-devel] pseudo abort with req '/proc/self/fd/3' Sam Liddicott
2024-02-29 10:31 ` Richard Purdie
2024-02-29 15:13 ` Sam Liddicott
[not found] ` <17B85E3B078DFE63.18468@lists.openembedded.org>
2024-04-06 11:03 ` Sam Liddicott
2024-04-07 10:04 ` Richard Purdie [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9ce5ba6c0ea52f2c636874c88051d216fd2f2c9f.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=bitbake-devel@lists.openembedded.org \
--cc=matt.cowell@nokia.com \
--cc=sam@liddicott.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).