KDE

5263 readers

104 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 9 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

[–] carlschwan@floss.social 2 points 9 months ago (1 children)

@zygoon @kde@lemmy.kde.social @kde kernel 3.10 was released more than 10 years ago and received a last update in 2017. Is that really a kernel still used in the wild?

Looking at https://lxr.kde.org/search?%21v=kf5-qt5&_filestring=&_string=sched.h, KDE does not do a clone3 directly. It's likely done by a dependency of Plasma :( But I might be wrong as I'm definitively not an expert in syscall

[–] zygoon@fosstodon.org 0 points 9 months ago (1 children)

@carlschwan @kde@lemmy.kde.social @kde@floss.social

Yeah, RHEL 7 uses it out of the box and is still supported, at least until June 2024: https://www.redhat.com/en/blog/end-maintenance-red-hat-enterprise-linux-7-almost-here

[–] Conan_Kudo@fosstodon.org 2 points 9 months ago (1 children)

@zygoon @carlschwan @kde@lemmy.kde.social @kde@floss.social It's likely coming from some usage of libseccomp somewhere. This also afflicts the container stack and such, which is why RHEL 9 containers on RHEL 7 are not supported.

Container/sandbox runtimes using libseccomp need to explicitly always allow clone3() through, or otherwise it will not fail correctly on RHEL 7.

[–] zygoon@fosstodon.org 1 points 9 months ago (2 children)

@Conan_Kudo @carlschwan @kde@lemmy.kde.social @kde@floss.social yeah, I strongly suspect seccomp. I’m debugging this now and I will share updates when I get to the bottom of the problem.

[–] Conan_Kudo@fosstodon.org 1 points 9 months ago* (last edited 9 months ago)

@zygoon @carlschwan @kde@lemmy.kde.social @kde@floss.social The clone3() call is done implicitly and automatically by glibc. It started with glibc 2.34. This is most likely a problem in the Ubuntu Core 22 runtime that KDE snaps are built on.

The fix is to patch out the logic that uses it for clone() in Ubuntu's glibc.