A user in enterprise support reported a low (<1/50) chance of network
crash (with soft lockups reported) when exiting ovs-tcpdump (a tcpdump
wrapper provided by Open vSwitch) which they could only resolve by
rebooting the host.
After reporting the issue upstream with a reproducer [1], an OVS
developer submitted a kernel patch which is now included 6.13 and some
stable kernels. With this patch, the reproducer does not seem to
trigger the issue anymore. Hence, backport the patch.
[1] https://mail.openvswitch.org/pipermail/ovs-discuss/2025-January/053423.html
Signed-off-by: Friedrich Weber <f.weber@proxmox.com>
Can be used to generate a package for testing a particular bugfix, or
new version, which can be shared with a small audience, without
reusing the current package version, or bumping to a version that
looks like our released kernels[0].
previously this could be accomplished by setting the PKGREL variable
to the revision and temporary suffix. PKGREL got dropped in:
de18530801 ("bump version to 6.2.16-8")
as each new version we release needs to have a ABI bump anyways (due
to module signing).
[0] e.g. new versions of submodules (ZFS), or packages shared in the
temp-dir of our CDN nodes
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Cherry-pick upstream commit f24f669d03f884a6ef95cca84317d0f329e93961
to avoid unnecessary performance penalty for setups with a new enough
CPU microcode update applied.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Adapted to context change in "arch/x86/kvm/cpuid.h", because of the
vcpu_supports_xsave_pkru() function that got added by Proxmox VE
downstream patch "kvm: xsave set: mask-out PKRU bit in xfeatures if
vCPU has no support". But otherwise clean cherry-pick from linux-next,
no functional changes.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
git will automatically change the length of the index hashes when
formatting a patch depending on what references are present in the
submodule. After pulling in the stable tags today, git wanted to add
a character to all hashes for me. Use --full-index when generating the
patches to avoid such issues in the future.
No functional change intended.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
This change breaks passthrough of the iGPU on older Intel Plattforms
(Skylake)
https://forum.proxmox.com/threads/.157266
The patch was orignally applied by Ubuntu upstream for an issue
unrelated to passthrough - flickering of the display with these chips,
where some comments suggest that setting intel_iommu=igfx_off does not
fix the issue, while the patch explicitly says it does the same as
setting intel_iommu=igfx_off - my quick glance at the code agrees with
the patch author, with the downside that with the patch you cannot
enable it again via kernel_cmdline.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2062951
As this is a regression, and our user-base does not seem to have
encountered the issue with flickering displays simply revert the
change for now. A proper fix seems to be in the makings in linux
upstream (according to the launchpad issue)
I tested this on an old machine we had lying around - reverting the
patch suppressed the message:
pci 0000:00:02.0: DMAR: Disabling IOMMU for graphics on this chipset
(also did not notice any flickering in a short graphic session
(wayland+kde)).
I'd suggest pulling this also into our 6.8 kernel (but this can also happen
after we get some feedback that it indeed fixes the issue of the
reporters in the forum)
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
the latest linux-stable pull I found in ubuntu-oracular was for 6.11.5
- this fix here seems targeted enough. see also the discussion
upstream:
https://lore.kernel.org/all/20241029163317.GA216411@nvidia.com/
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
As reported in the community forum [0], containers requiring cgroup v1
would not start anymore, even when systemd.unified_cgroup_hierarchy=0
was set on the kernel commandline. The error message would be:
> cgfsng_setup_limits_legacy: 3442 No such file or directory - Failed to set "memory.limit_in_bytes" to "536870912"
Kernel commit e93d4166b40a ("mm: memcg: put cgroup v1-specific code
under a config option"), which was first shipped in v6.11, made it
necessary to explicitly enable the new associated Kconfig flag.
[0]: https://forum.proxmox.com/threads/156830/
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
[TL: note that the commit was first shipped with 6.11 ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Fixes rare read corruption issues using the in kernel ceph client.
On incomplete read requests, the clean tail flag should make sure to
zero fill the remaining bytes for the subrequest.
If the iov iterator is not at the correct position, e.g., because the
subreq->transferred was not yet updated, this can however zero fill
downloaded data, corrupting the read content.
Link to issue:
https://bugzilla.proxmox.com/show_bug.cgi?id=5683
Link to upstream issue:
https://bugzilla.kernel.org/show_bug.cgi?id=219237
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
[ TL: mention an specific example for subreq misalignment ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Reported in the community forum [0].
This fixes an issue with read/write operations done on ocfs2 with
io_uring. This has caused QEMU guests to be unable to determine the file
format at [1] because of an unsuccessful read and therefore could not
boot, which has been resolved with this patch.
This patch is already merged in Jens Axboe's linux-block tree and also
merged in the mainline v6.12 prepatch kernels:
> # git tag --contains c0a9d496e0fece67db777bd48550376cf2960c47
> v6.12-rc1
> v6.12-rc2
> v6.13-rc3
[0] https://forum.proxmox.com/threads/140273/post-702007
[1] https://elixir.bootlin.com/qemu/v9.0.2/source/block.c#L1031
Signed-off-by: Daniel Kral <d.kral@proxmox.com>
cherry-picked from Linux kernel.org upstream commit
5560a612c20d3daacbf5da7913deefa5c31742f4
The issue was reported in the enterprise support. The customer
contacted the ledmon maintainer, who found that it is not an issue
with ledmon, bisected the kernel and came up with this fix
Originally-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
picked from v6.9.8, the bug can cause lost NFS connections according to
upstream, and possibly corrupt backups according to our user report.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
