KDE

5407 readers

97 users here now

KDE is an international technology team creating user-friendly free and open source software for desktop and portable computing. KDE’s software runs on GNU/Linux, BSD and other operating systems, including Windows.

Plasma 6 Bugs

If you encounter a bug, proceed to https://bugs.kde.org, check whether it has been reported.

If it hasn't, report it yourself.

PLEASE THINK CAREFULLY BEFORE POSTING HERE.

Developers do not look for reports on social media, so they will not see it and all it does is clutter up the feed.

founded 1 year ago

MODERATORS

carlschwan@lemmy.kde.social

Bro666@lemmy.kde.social

herzenschein@pawb.social

Aniqakhokhar@lemmy.kde.social

There's some mismatch between Linux kernel 3.10 and #KDE that wants to use clone3 to create a process thread. (fosstodon.org)

submitted 10 months ago by zygoon@fosstodon.org to c/kde@lemmy.kde.social

7 comments fedilink hide all child comments

There's some mismatch between Linux kernel 3.10 and #KDE that wants to use clone3 to create a process thread.

Do I know anyone from @kde@lemmy.kde.social @kde@floss.social who is able to assist with debugging it further?

The system call clone3 has been added to linux 5.3 but it seems that KDE does not do any fallback in case the system call is rejected with EPERM.

you are viewing a single comment's thread
view the rest of the comments

[–] brauner@mastodon.social 1 points 10 months ago (1 children)

@zygoon @kde@lemmy.kde.social @kde@floss.social because any reasonable implementation will treat EPERM from a process creation system call as a fatal error. If this is e.g., blocked through seccomp. ENOSYS is the correct error to return. It's just naive seccomp sandboxes that started this EPERM nonsense. So I'd rule that out first. Unless you're using something that requires specific capabilities such as creating a process with a specific PID. That can legitimately return EPERM.

[–] zygoon@fosstodon.org 1 points 10 months ago

@brauner @kde@lemmy.kde.social @kde@floss.social

Thanks for the insight. I was surprised by EPERM, would have expected ENOSYS as well.

Looks like EPERM is most likely coming out of unknow system call name being filtered-out by snap-seccomp compiler. I'll update snapd to 2.61.1 to avoid chasing fixed bugs and then see if there's something to improve in the compiler.