Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gracefully handle the case of missing libvsdo.so #966

Closed
nyh opened this issue May 6, 2018 · 2 comments
Closed

Gracefully handle the case of missing libvsdo.so #966

nyh opened this issue May 6, 2018 · 2 comments

Comments

@nyh
Copy link
Contributor

nyh commented May 6, 2018

Issue #821 describes a new OSv kernel which was run with an image missing libvdso.so, and prepare_argv() (called when running an application) aborts.

I think we should gracefully handle this case. If libvdso.so is missing, a minor feature is missing (the AT_SYSINFO_EHDR auxv setting), it's not a reason to crash immediately. I think at worst perhaps we should debug() a message?

Looking at this code also made me wonder about why we need to open a separate copy of libvso.so for each application. Unlike libenviron.so whose entire raison d'etre was to be separate for separate ELF namespace, I think (but please correct me if I'm wrong), libvdso.so could have been loaded once and reused. However, I think this is of minor importance - the savings would be minimal.

@wkozaczuk
Copy link
Collaborator

I was trying to prepare a patch for this and noticed that when some programs run to create image - /tools/mkfs.so, /tools/cpiod.so, /zfs.so - file system is not present yet or mounted how come loading vdso "succeeds":

_libvdso = program->get_library("libvdso.so");
    if (!_libvdso) {
        abort("could not load libvdso.so\n");
    }

I noticed that program::load_object() returns some kind of stub (end of the method):

} else {
        printf("==> [%03d] program::load_object() returned STUB for %s!\n", sched::thread::current()->id(), name.c_str());
        return std::shared_ptr<object>();
    }

but that does not seem to happen for libvdso.so.

Also if we wanted to load vdso once should we try it eagerly earlier than prepare_args()? I assume we would want to make _libvdso a static member of the application class.

@wkozaczuk
Copy link
Collaborator

Regarding my last comment I realized that libvdso along with many other shared libraries is added to loader.elf as part of bootfs.manifest (look at bootfs.S). Therefore kernel is able to load libvdso when executing zpool.so or mkfs.so apps because there is only ramfs (aka bootfs) filesystem mounted.
This also means that many libraries from usr.manifest.skel are actually duplicated in loader.elf. But that is subject for another discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants