I apologise in advance if I am in the wrong forum. I have a concern about a particular Linux API (AIO). A specific kernel function (io_destroy) blocks for a long time on 5.15.0-40-generic. I’ve observed the same on an older kernel. It is so slow that I am wondering if this is a performance bug?
My question is, where should I report this? I can provide my observations and a minimally reproducible C test code.
Great question! it is usually either subsystem mailing list or kernel bugzilla.
For the correct workflow on how to report upstream kernel bugs you can follow this excellent kernel newbies article. It tells you step by step, how to prepare bug report and where to submit it.
Once you submit it to a mailing list of kernel bugzilla, drop the URL to it here. I would be delighted to read it and see if I know anybody who would be able to help with it further!
I’m not quite sure what you mean by roadmaps for new releases. Can you please elaborate what sort of information you are looking for, or expect to find?
Kinetic Release Schedule has Kernel Feature Freeze as 6th of October. v5.19 is out and is prepared to be in Kinetic, it is already in kinetic-proposed with some known regressions.
It is unlikely that v6.0 will be out and stabalised in time to make it before Kernel Feature Freeze.
if there are important features to backport and include in Kinetic kernel, this can be requested via ubuntu-bug linux or via email to kernel-team@lists.ubuntu.com (archives) which is the Public Ubuntu Kernel Mailing list used for feature discussion, next kernel developments, and patch reviews.
Kinetic and Jammy will have other kernels too, for specific partners and OEMs which will have features specific to a given partner. PMs of those partners can query things privately via their Salesforce account.
Could you please check the 5.19.4 builds ? Only arm64 and s390 builds completed successfully.
The amd64 build looks like it failed due to a missing header file (likely wrong path for -I include files) :
fuse_mnt.c:17:10: fatal error: fuse.h: No such file or directory
@thetick the mainline builds ppa is entirely unsupported. it is merely there to provide a means to test wether a bug in the official kernel has been fixed upstream in the https://kernel.org/ releases. You are not supposed to run them full time, so the fact that a build or two fails should be irrelevant to anyone outside the kernel team for whom it should be very low priority to fix.
this is not true, they do work exactly the same everywhere but on kernels that lack security patches the confinement runs in degraded mode (so they run fine, but less secured)
also, by design you can currently not run two LSMs at the same time, so distros that default to selinux will not be able to use appamor (which snaps are built around).
on such distros you will always see a degraded security model until the upstream kernel implements LSM stacking.
(on a sidenote, the one missing patch you mention is an apparmor patch. on selinux based distros adding this patch would have no effect anyway)
Snaps do work properly on other distributions. Depending on their LSM configuration, the best possible confinement is used by snapd. Snapd team has actively worked with other distributions to enable more kernel LSM features in their distributions to improve snaps security confinement on other distributions. Specifically upstreaming & working with other distributions to enable LSM stacking and enable selinux & apparmor stacking at the same time to enable all universally known confinement capabilities. If your particular distribution does not yet enable stacked LSM with apparmor, you may want to ask those distributions to do exactly that.
As a separate note, Ubuntu kernels supports AppArmor, Selinux, Smack in additional to other smaller scoped LSMs. And there are users on Ubuntu that choose to use other LSM in addition to or instead of Apparmor and are fully supported. So there are no limitations for other distributions to do what Ubuntu kernels do by default, or as an opt in.
As a developer I can use these mainline kernel builds for testing instead of building them myself. If they are not built then if needed for my testing I may need to build the kernel myself. So I am not a Ubuntu developer but in open source world we share our achievements. No level of support is asked or expected but contributions (bug reports, patches, testing) are usually welcome.
Note : I don’t run mainline kernels outside of specific test machines.
Hi guys. I have a 20.04 (fossa) which I upgrade the default kernel which came (5.4.0-x) to 5.17.9-051709 which was one of the new Kernel versions when I did that. Don’t exactly remember why, but it seems that there was an issue that this kernel solved on my machine, a T430 ThinkPad. It worked fine no problem, still working, but the only thing is that I missed are linux-tools-generic and linux-cloud-tools-generic packages which were from 5.4.0 series. Even today if I try to install them it gets the default to 5.4.0-x version (linux-cloud-tools-5.4.0-125…). I already uninstalled the 5.4.0 series kernel completely from my machine, but the tools keep installing from the previous version. I try to locate a linux-tools-5.17.9-051709-generic but didn’t find anywhere. Do I have to compile them ? Why these packages are not included in the kernel generic files ? tks.