[pve-devel] [PATCH qemu-server v2] use machine version in vga default type selection
If we get an VM machine older than 2.9 we use the old selection
expression for the VGA type. This allows to live migrate VMs to PVE
5.0 from beta 1 and PVE 4.4 again.
Signed-off-by: Thomas Lamprecht
---
changes v1 -> v2:
* renamed from "add workaround for pve 4.4 to 5.0 live migration"
* move code handling this to PVE 5.0, as this is how we do it normally
* obtain from touching the config, this is to much of a hack
PVE/QemuServer.pm | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index 79a65ee..01753d9 100644
--- a/PVE/QemuServer.pm
+++ b/PVE/QemuServer.pm
@@ -2925,7 +2925,11 @@ sub config_to_command {
$vga = 'qxl' if $qxlnum;
if (!$vga) {
- $vga = (!$winversion || $winversion >= 6) ? 'std' : 'cirrus';
+ if (qemu_machine_feature_enabled($machine_type, $kvmver, 2, 9)) {
+ $vga = (!$winversion || $winversion >= 6) ? 'std' : 'cirrus';
+ } else {
+ $vga = ($winversion >= 6) ? 'std' : 'cirrus';
+ }
}
# enable absolute mouse coordinates (needed by vnc)
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [RFC qemu-server stable-4] add workaround for pve 4.4 to 5.0 live migration
Hi,
On 07/11/2017 10:06 PM, Stefan Priebe - Profihost AG wrote:
Hello,
Am 11.07.2017 um 16:40 schrieb Thomas Lamprecht:
commit 85909c04c49879f5fffa366fc3233eee2b157e97 switched from cirrus
to vga for non windows OSs.
This adds an artificial blocker on live migrations from PVE 4.X to
PVE 5.0.
Address it in PVE 4.4 by explicitly setting cirrus in the config if
it would be used, so that a PVE 5.0 starts up the correct hardware in
the case of a migration. Do it only on running VMs with online
migration enabled.
Do not clean it up, as this would then make live migration fail again
until the VM had a real poweroff and power on cycle even from PVE 5.0
to PVE 5.0.
While not the nicest way it is a short and valid solution and doesn't
adds hackery in new code. We may also touch the config only on the
source site until migration phase 3 completes.
this is a pretty hacky approach i don't like.
yes, I know and not proud of it :)
We will probably opt for the second approach mentioned in the patchs
comment section.
The one where I check the qemu machine version.
What about doing something different which is a more general approach an
can be used for pve 6, 7 as well:
1.) write at each vm start pve-manager version to a field in the
vm conf f.e. pveversion: 4.4
2.) while doing an online migration check if there are special things to
consider f. e. default vga = cirrus if !defined($conf->{vga} &&
$conf->{pveversion} < 5;
Hmm, better approach for sure, but then you would need to rewrite the
version at some point
and that cannot be after migration, as there the VM still runs with the
"old" machines devices.
One a discussion here we came to another approach, which would be even
more general
and easier to maintain, at least for the VM case.
Extract all devices and their current settings from the VM once locked
for migration and pass this to the target side.
There use the actual current device info to start the VM listening for
an incoming migration.
This would prevent such things once and for all and had also hot
plugging various devices in mind,
even if "manual" hot-plugged.
Thanks for your input! The config version is a nice idea, but for this
specific case too much a
hassle at the moment, IMO, as it needs to touch both pve 4 and 5.
cheers,
Thomas
Greets,
Stefan
$
Signed-off-by: Thomas Lamprecht
---
Another approach would be to check the machine type on the target side and if
older than *-2.9 use cirrus, if not explicitly set already.
But this would then add code on PVE 5.0 which we would need to maintain for a
bit of time, so I'm not sure if that would be the nicer solution...
PVE/QemuMigrate.pm | 8
1 file changed, 8 insertions(+)
diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
index e6f147e..6cfca0b 100644
--- a/PVE/QemuMigrate.pm
+++ b/PVE/QemuMigrate.pm
@@ -429,6 +429,14 @@ sub phase1 {
my $conf = $self->{vmconf};
+# HACK: avoid migration failure to 5.0 as the VGA default has changed
+if (!defined($conf->{vga}) && $self->{running} && $self->{opts}->{online})
{
+ my $winversion = PVE::QemuServer::windows_version($conf->{ostype});
+ if ($winversion < 6) {
+ $conf->{vga} = 'cirrus';
+ }
+}
+
# set migrate lock in config file
$conf->{lock} = 'migrate';
PVE::QemuConfig->write_config($vmid, $conf);
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [RFC qemu-server stable-4] add workaround for pve 4.4 to 5.0 live migration
Hello,
Am 11.07.2017 um 16:40 schrieb Thomas Lamprecht:
> commit 85909c04c49879f5fffa366fc3233eee2b157e97 switched from cirrus
> to vga for non windows OSs.
>
> This adds an artificial blocker on live migrations from PVE 4.X to
> PVE 5.0.
> Address it in PVE 4.4 by explicitly setting cirrus in the config if
> it would be used, so that a PVE 5.0 starts up the correct hardware in
> the case of a migration. Do it only on running VMs with online
> migration enabled.
> Do not clean it up, as this would then make live migration fail again
> until the VM had a real poweroff and power on cycle even from PVE 5.0
> to PVE 5.0.
> While not the nicest way it is a short and valid solution and doesn't
> adds hackery in new code. We may also touch the config only on the
> source site until migration phase 3 completes.
this is a pretty hacky approach i don't like.
What about doing something different which is a more general approach an
can be used for pve 6, 7 as well:
1.) write at each vm start pve-manager version to a field in the
vm conf f.e. pveversion: 4.4
2.) while doing an online migration check if there are special things to
consider f. e. default vga = cirrus if !defined($conf->{vga} &&
$conf->{pveversion} < 5;
Greets,
Stefan
$
> Signed-off-by: Thomas Lamprecht
> ---
>
> Another approach would be to check the machine type on the target side and if
> older than *-2.9 use cirrus, if not explicitly set already.
> But this would then add code on PVE 5.0 which we would need to maintain for a
> bit of time, so I'm not sure if that would be the nicer solution...
>
> PVE/QemuMigrate.pm | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
> index e6f147e..6cfca0b 100644
> --- a/PVE/QemuMigrate.pm
> +++ b/PVE/QemuMigrate.pm
> @@ -429,6 +429,14 @@ sub phase1 {
>
> my $conf = $self->{vmconf};
>
> +# HACK: avoid migration failure to 5.0 as the VGA default has changed
> +if (!defined($conf->{vga}) && $self->{running} &&
> $self->{opts}->{online}) {
> + my $winversion = PVE::QemuServer::windows_version($conf->{ostype});
> + if ($winversion < 6) {
> + $conf->{vga} = 'cirrus';
> + }
> +}
> +
> # set migrate lock in config file
> $conf->{lock} = 'migrate';
> PVE::QemuConfig->write_config($vmid, $conf);
>
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH 2/4] drop patches applied upstream
Signed-off-by: Thomas Lamprecht
---
...64-0001-Revert-mm-enlarge-stack-guard-gap.patch | 461 --
...ert-mm-do-not-collapse-stack-gap-into-THP.patch | 48 --
...03-mm-larger-stack-guard-gap-between-vmas.patch | 940 -
...mm-fix-new-crash-in-unmapped_area_topdown.patch | 54 --
...cp-tcp-do-not-inherit-mc_list-from-parent.patch | 54 --
...ip6_find_1stfragopt-return-value-properly.patch | 96 ---
...nt-overrun-when-parsing-v6-header-options.patch | 244 --
...-inherit-ipv6_-mc-ac-fl-_list-from-parent.patch | 46 -
...p-do-not-inherit-ipv6_mc_list-from-parent.patch | 78 --
...-out-of-bound-writes-in-__ip6_append_data.patch | 79 --
Makefile | 13 -
...-Set-internal-device-max-mtu-to-ETH_MAX_M.patch | 41 -
...yzen-01-make-use-of-raw_spinlock-variants.patch | 303 ---
...-Use-regular-interrupt-instead-of-chained.patch | 165
14 files changed, 2622 deletions(-)
delete mode 100644 CVE-2017-100364-0001-Revert-mm-enlarge-stack-guard-gap.patch
delete mode 100644
CVE-2017-100364-0002-Revert-mm-do-not-collapse-stack-gap-into-THP.patch
delete mode 100644
CVE-2017-100364-0003-mm-larger-stack-guard-gap-between-vmas.patch
delete mode 100644
CVE-2017-100364-0004-mm-fix-new-crash-in-unmapped_area_topdown.patch
delete mode 100644
CVE-2017-8890-dccp-tcp-do-not-inherit-mc_list-from-parent.patch
delete mode 100644
CVE-2017-9074-2-ipv6-Check-ip6_find_1stfragopt-return-value-properly.patch
delete mode 100644
CVE-2017-9074-ipv6-Prevent-overrun-when-parsing-v6-header-options.patch
delete mode 100644
CVE-2017-9075-sctp-do-not-inherit-ipv6_-mc-ac-fl-_list-from-parent.patch
delete mode 100644
CVE-2017-9076_9077-ipv6-dccp-do-not-inherit-ipv6_mc_list-from-parent.patch
delete mode 100644
CVE-2017-9242-ipv6-fix-out-of-bound-writes-in-__ip6_append_data.patch
delete mode 100644 openvswitch-Set-internal-device-max-mtu-to-ETH_MAX_M.patch
delete mode 100644 pinctl-amd-ryzen-01-make-use-of-raw_spinlock-variants.patch
delete mode 100644
pinctl-amd-ryzen-02-Use-regular-interrupt-instead-of-chained.patch
diff --git a/CVE-2017-100364-0001-Revert-mm-enlarge-stack-guard-gap.patch
b/CVE-2017-100364-0001-Revert-mm-enlarge-stack-guard-gap.patch
deleted file mode 100644
index 5b23039..000
--- a/CVE-2017-100364-0001-Revert-mm-enlarge-stack-guard-gap.patch
+++ /dev/null
@@ -1,461 +0,0 @@
-From 0a0e88a03210365fb82b7ab9cebfccca31aff608 Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?Fabian=20Gr=C3=BCnbichler?=
-Date: Fri, 23 Jun 2017 08:25:20 +0200
-Subject: [PATCH 1/4] Revert "mm: enlarge stack guard gap"
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-This reverts commit fe388e5751e74b3534ee21d01b999795dfc83d39.
-
-Signed-off-by: Fabian Grünbichler
- include/linux/mm.h | 40 +++---
- arch/ia64/mm/fault.c | 2 +-
- fs/exec.c| 8 +--
- fs/proc/task_mmu.c | 11 ++--
- mm/gup.c | 4 +-
- mm/memory.c | 35 +++-
- mm/mmap.c| 152 ++-
- 7 files changed, 102 insertions(+), 150 deletions(-)
-
-diff --git a/include/linux/mm.h b/include/linux/mm.h
-index fbe65ceafb94..3978a350e9e4 100644
a/include/linux/mm.h
-+++ b/include/linux/mm.h
-@@ -1366,11 +1366,39 @@ int clear_page_dirty_for_io(struct page *page);
-
- int get_cmdline(struct task_struct *task, char *buffer, int buflen);
-
-+/* Is the vma a continuation of the stack vma above it? */
-+static inline int vma_growsdown(struct vm_area_struct *vma, unsigned long
addr)
-+{
-+ return vma && (vma->vm_end == addr) && (vma->vm_flags & VM_GROWSDOWN);
-+}
-+
- static inline bool vma_is_anonymous(struct vm_area_struct *vma)
- {
- return !vma->vm_ops;
- }
-
-+static inline int stack_guard_page_start(struct vm_area_struct *vma,
-+ unsigned long addr)
-+{
-+ return (vma->vm_flags & VM_GROWSDOWN) &&
-+ (vma->vm_start == addr) &&
-+ !vma_growsdown(vma->vm_prev, addr);
-+}
-+
-+/* Is the vma a continuation of the stack vma below it? */
-+static inline int vma_growsup(struct vm_area_struct *vma, unsigned long addr)
-+{
-+ return vma && (vma->vm_start == addr) && (vma->vm_flags & VM_GROWSUP);
-+}
-+
-+static inline int stack_guard_page_end(struct vm_area_struct *vma,
-+ unsigned long addr)
-+{
-+ return (vma->vm_flags & VM_GROWSUP) &&
-+ (vma->vm_end == addr) &&
-+ !vma_growsup(vma->vm_next, addr);
-+}
-+
- int vma_is_stack_for_current(struct vm_area_struct *vma);
-
- extern unsigned long move_page_tables(struct vm_area_struct *vma,
-@@ -2111,22 +2139,16 @@ void page_cache_async_readahead(struct address_space
*mapping,
- pgoff_t offset,
- unsigned long size);
-
--extern unsigned long stack_guard_gap;
- /* Generic expand
[pve-devel] [RFC qemu-server stable-4] add workaround for pve 4.4 to 5.0 live migration
commit 85909c04c49879f5fffa366fc3233eee2b157e97 switched from cirrus
to vga for non windows OSs.
This adds an artificial blocker on live migrations from PVE 4.X to
PVE 5.0.
Address it in PVE 4.4 by explicitly setting cirrus in the config if
it would be used, so that a PVE 5.0 starts up the correct hardware in
the case of a migration. Do it only on running VMs with online
migration enabled.
Do not clean it up, as this would then make live migration fail again
until the VM had a real poweroff and power on cycle even from PVE 5.0
to PVE 5.0.
While not the nicest way it is a short and valid solution and doesn't
adds hackery in new code. We may also touch the config only on the
source site until migration phase 3 completes.
Signed-off-by: Thomas Lamprecht
---
Another approach would be to check the machine type on the target side and if
older than *-2.9 use cirrus, if not explicitly set already.
But this would then add code on PVE 5.0 which we would need to maintain for a
bit of time, so I'm not sure if that would be the nicer solution...
PVE/QemuMigrate.pm | 8
1 file changed, 8 insertions(+)
diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
index e6f147e..6cfca0b 100644
--- a/PVE/QemuMigrate.pm
+++ b/PVE/QemuMigrate.pm
@@ -429,6 +429,14 @@ sub phase1 {
my $conf = $self->{vmconf};
+# HACK: avoid migration failure to 5.0 as the VGA default has changed
+if (!defined($conf->{vga}) && $self->{running} && $self->{opts}->{online})
{
+ my $winversion = PVE::QemuServer::windows_version($conf->{ostype});
+ if ($winversion < 6) {
+ $conf->{vga} = 'cirrus';
+ }
+}
+
# set migrate lock in config file
$conf->{lock} = 'migrate';
PVE::QemuConfig->write_config($vmid, $conf);
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH 4/4] update abi-previous after ABI bump
Signed-off-by: Thomas Lamprecht --- abi-previous | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/abi-previous b/abi-previous index be64086..582ece5 100644 --- a/abi-previous +++ b/abi-previous @@ -5129,8 +5129,8 @@ EXPORT_SYMBOL_GPL drivers/cpufreq/speedstep-lib 0x1b1f2bdaspeedstep_get_freqs EXPORT_SYMBOL_GPL drivers/cpufreq/speedstep-lib 0x2b67f096 speedstep_get_frequency EXPORT_SYMBOL_GPL drivers/cpufreq/speedstep-lib 0xd7ab2c0c speedstep_detect_processor EXPORT_SYMBOL_GPL drivers/crypto/ccp/ccp 0x04773b60ccp_present -EXPORT_SYMBOL_GPL drivers/crypto/ccp/ccp 0x0b07b237ccp_enqueue_cmd EXPORT_SYMBOL_GPL drivers/crypto/ccp/ccp 0x3a1a3979ccp_version +EXPORT_SYMBOL_GPL drivers/crypto/ccp/ccp 0xca65c887ccp_enqueue_cmd EXPORT_SYMBOL_GPL drivers/crypto/qat/qat_common/intel_qat 0x02209ec1 adf_cfg_add_key_value_param EXPORT_SYMBOL_GPL drivers/crypto/qat/qat_common/intel_qat 0x0adfd40d adf_devmgr_pci_to_accel_dev EXPORT_SYMBOL_GPL drivers/crypto/qat/qat_common/intel_qat 0x0fd68d94 adf_dev_get @@ -8078,8 +8078,8 @@ EXPORT_SYMBOL_GPL drivers/uio/uio 0x1e9ccddb uio_unregister_device EXPORT_SYMBOL_GPL drivers/uio/uio 0x2c16c607 uio_event_notify EXPORT_SYMBOL_GPL drivers/usb/atm/usbatm 0xa6547160usbatm_usb_disconnect EXPORT_SYMBOL_GPL drivers/usb/atm/usbatm 0xe71c2cebusbatm_usb_probe -EXPORT_SYMBOL_GPL drivers/usb/chipidea/ci_hdrc 0x7d5953cd ci_hdrc_add_device EXPORT_SYMBOL_GPL drivers/usb/chipidea/ci_hdrc 0xece1a624 ci_hdrc_remove_device +EXPORT_SYMBOL_GPL drivers/usb/chipidea/ci_hdrc 0xfc968b2c ci_hdrc_add_device EXPORT_SYMBOL_GPL drivers/usb/common/ulpi 0x1ac5ff73 ulpi_register_interface EXPORT_SYMBOL_GPL drivers/usb/common/ulpi 0x1c51ee5e ulpi_unregister_interface EXPORT_SYMBOL_GPL drivers/usb/common/ulpi 0x221920e1 ulpi_write @@ -11322,6 +11322,7 @@ EXPORT_SYMBOL_GPL vmlinux 0x30021f76__pm_stay_awake EXPORT_SYMBOL_GPL vmlinux 0x30049e71 device_move EXPORT_SYMBOL_GPL vmlinux 0x30204c66 skb_to_sgvec EXPORT_SYMBOL_GPL vmlinux 0x30281513 pci_device_is_present +EXPORT_SYMBOL_GPL vmlinux 0x302dda19 intel_svm_bind_mm EXPORT_SYMBOL_GPL vmlinux 0x302e5b55 pm_generic_thaw_noirq EXPORT_SYMBOL_GPL vmlinux 0x3031cd69 __platform_create_bundle EXPORT_SYMBOL_GPL vmlinux 0x304615e2 devm_of_phy_get @@ -12786,6 +12787,7 @@ EXPORT_SYMBOL_GPL vmlinux 0x845a8f84 register_wide_hw_breakpoint EXPORT_SYMBOL_GPL vmlinux 0x84723b21 xenbus_dev_is_online EXPORT_SYMBOL_GPL vmlinux 0x8487a2b6 flush_work EXPORT_SYMBOL_GPL vmlinux 0x848d8811 ata_pci_bmdma_init_one +EXPORT_SYMBOL_GPL vmlinux 0x84987968 intel_svm_unbind_mm EXPORT_SYMBOL_GPL vmlinux 0x84a685a7 gpiochip_unlock_as_irq EXPORT_SYMBOL_GPL vmlinux 0x84a7f9dc wm8350_clear_bits EXPORT_SYMBOL_GPL vmlinux 0x84aace8f vfs_getxattr @@ -13237,7 +13239,6 @@ EXPORT_SYMBOL_GPL vmlinux 0x9df63aa4 fuse_request_alloc EXPORT_SYMBOL_GPL vmlinux 0x9dfc6564 posix_acl_default_xattr_handler EXPORT_SYMBOL_GPL vmlinux 0x9dff20e0 power_supply_unregister EXPORT_SYMBOL_GPL vmlinux 0x9e0ccc90 rio_request_outb_dbell -EXPORT_SYMBOL_GPL vmlinux 0x9e15213c intel_svm_bind_mm EXPORT_SYMBOL_GPL vmlinux 0x9e201155 cppc_get_perf_caps EXPORT_SYMBOL_GPL vmlinux 0x9e2d3b2e kernfs_find_and_get_ns EXPORT_SYMBOL_GPL vmlinux 0x9e472f5f snmp_fold_field @@ -14416,7 +14417,6 @@ EXPORT_SYMBOL_GPL vmlinux 0xdf89bd34nvme_init_ctrl EXPORT_SYMBOL_GPL vmlinux 0xdfb2c843 __lock_page_killable EXPORT_SYMBOL_GPL vmlinux 0xdfd91574 da903x_register_notifier EXPORT_SYMBOL_GPL vmlinux 0xdfe0684f blk_queue_flush_queueable -EXPORT_SYMBOL_GPL vmlinux 0xdff11e5d intel_svm_unbind_mm EXPORT_SYMBOL_GPL vmlinux 0xe007de41 kallsyms_lookup_name EXPORT_SYMBOL_GPL vmlinux 0xe01bc9ef securityfs_create_dentry EXPORT_SYMBOL_GPL vmlinux 0xe0288768 regmap_get_max_register @@ -14880,6 +14880,7 @@ EXPORT_SYMBOL_GPL vmlinux 0xf9a53654 crypto_remove_spawns EXPORT_SYMBOL_GPL vmlinux 0xf9ae61e8 tps80031_ext_power_req_config EXPORT_SYMBOL_GPL vmlinux 0xf9c0a293 klp_disable_patch EXPORT_SYMBOL_GPL vmlinux 0xf9ca3160 ata_id_xfermask +EXPORT_SYMBOL_GPL vmlinux 0xf9d9264e xen_have_vector_callback EXPORT_SYMBOL_GPL vmlinux 0xf9de8d91 thp_get_unmapped_area EXPORT_SYMBOL_GPL vmlinux 0xf9e7544e mddev_suspend EXPORT_SYMBOL_GPL vmlinux 0xf9f07412 debugfs_attr_read -- 2.11.0 ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH 0/4] update kernel to latest ubuntu version
Updates to latest ubuntu kernel which includes several bug fixes and allows us to drop quite some patches now adopted by them too. I tried to use Fabians update style. Tested common problem areas of updates, live migration (old->new, new->old, new->new), storages (ZFS, ceph), all with and without some load tests. Thomas Lamprecht (4): update kernel source to Ubuntu-4.10.0-26.30 drop patches applied upstream bump version to 4.10.17-16, bump ABI to 4.10.17-1-pve update abi-previous after ABI bump ...64-0001-Revert-mm-enlarge-stack-guard-gap.patch | 461 -- ...ert-mm-do-not-collapse-stack-gap-into-THP.patch | 48 -- ...03-mm-larger-stack-guard-gap-between-vmas.patch | 940 - ...mm-fix-new-crash-in-unmapped_area_topdown.patch | 54 -- ...cp-tcp-do-not-inherit-mc_list-from-parent.patch | 54 -- ...ip6_find_1stfragopt-return-value-properly.patch | 96 --- ...nt-overrun-when-parsing-v6-header-options.patch | 244 -- ...-inherit-ipv6_-mc-ac-fl-_list-from-parent.patch | 46 - ...p-do-not-inherit-ipv6_mc_list-from-parent.patch | 78 -- ...-out-of-bound-writes-in-__ip6_append_data.patch | 79 -- Makefile | 17 +- abi-previous | 9 +- changelog.Debian | 8 + ...-Set-internal-device-max-mtu-to-ETH_MAX_M.patch | 41 - ...yzen-01-make-use-of-raw_spinlock-variants.patch | 303 --- ...-Use-regular-interrupt-instead-of-chained.patch | 165 proxmox-ve/changelog.Debian| 6 + submodules/ubuntu-zesty| 2 +- 18 files changed, 22 insertions(+), 2629 deletions(-) delete mode 100644 CVE-2017-100364-0001-Revert-mm-enlarge-stack-guard-gap.patch delete mode 100644 CVE-2017-100364-0002-Revert-mm-do-not-collapse-stack-gap-into-THP.patch delete mode 100644 CVE-2017-100364-0003-mm-larger-stack-guard-gap-between-vmas.patch delete mode 100644 CVE-2017-100364-0004-mm-fix-new-crash-in-unmapped_area_topdown.patch delete mode 100644 CVE-2017-8890-dccp-tcp-do-not-inherit-mc_list-from-parent.patch delete mode 100644 CVE-2017-9074-2-ipv6-Check-ip6_find_1stfragopt-return-value-properly.patch delete mode 100644 CVE-2017-9074-ipv6-Prevent-overrun-when-parsing-v6-header-options.patch delete mode 100644 CVE-2017-9075-sctp-do-not-inherit-ipv6_-mc-ac-fl-_list-from-parent.patch delete mode 100644 CVE-2017-9076_9077-ipv6-dccp-do-not-inherit-ipv6_mc_list-from-parent.patch delete mode 100644 CVE-2017-9242-ipv6-fix-out-of-bound-writes-in-__ip6_append_data.patch delete mode 100644 openvswitch-Set-internal-device-max-mtu-to-ETH_MAX_M.patch delete mode 100644 pinctl-amd-ryzen-01-make-use-of-raw_spinlock-variants.patch delete mode 100644 pinctl-amd-ryzen-02-Use-regular-interrupt-instead-of-chained.patch -- 2.11.0 ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH 3/4] bump version to 4.10.17-16, bump ABI to 4.10.17-1-pve
Signed-off-by: Thomas Lamprecht --- Makefile| 4 ++-- changelog.Debian| 8 proxmox-ve/changelog.Debian | 6 ++ 3 files changed, 16 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 806dcd4..dc293f6 100644 --- a/Makefile +++ b/Makefile @@ -1,8 +1,8 @@ RELEASE=5.0 # also update proxmox-ve/changelog if you change KERNEL_VER or KREL -KERNEL_VER=4.10.15 -PKGREL=15 +KERNEL_VER=4.10.17 +PKGREL=16 # also include firmware of previous version into # the fw package: fwlist-2.6.32-PREV-pve KREL=1 diff --git a/changelog.Debian b/changelog.Debian index 29facbd..4c1b45d 100644 --- a/changelog.Debian +++ b/changelog.Debian @@ -1,3 +1,11 @@ +pve-kernel (4.10.17-16) unstable; urgency=medium + + * update to Ubuntu 4.10.0-26.30 (based on stable kernel 4.10.17) + + * bump ABI to 4.10.17-1-pve + + -- Proxmox Support Team Tue, 11 Jul 2017 09:55:44 +0200 + pve-kernel (4.10.15-15) unstable; urgency=medium * replace CVE-2017-100364 fix and follow-up with upstream version diff --git a/proxmox-ve/changelog.Debian b/proxmox-ve/changelog.Debian index 8a4af00..1e6f0a4 100644 --- a/proxmox-ve/changelog.Debian +++ b/proxmox-ve/changelog.Debian @@ -1,3 +1,9 @@ +proxmox-ve (5.0-16) unstable; urgency=medium + + * depend on newest 4.10.17-1-pve kernel + + -- Proxmox Support Team Tue, 11 Jul 2017 11:11:35 +0200 + proxmox-ve (5.0-10) unstable; urgency=medium * depend on newest 4.10.15-1-pve kernel -- 2.11.0 ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH 1/4] update kernel source to Ubuntu-4.10.0-26.30
Signed-off-by: Thomas Lamprecht --- this requires updating our kernel mirror repo submodules/ubuntu-zesty | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/submodules/ubuntu-zesty b/submodules/ubuntu-zesty index 1106717..56389f2 16 --- a/submodules/ubuntu-zesty +++ b/submodules/ubuntu-zesty @@ -1 +1 @@ -Subproject commit 11067176f5d6bcc44dc73ab355a30c6838c597b0 +Subproject commit 56389f24b205f2464626d56bc15c5a6ceeeceedf -- 2.11.0 ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH manager 2/3] fix breaking gui when trying to edit a bindmount rootfs
when having a simple directory as rootfs,
trying to edit it in the gui broke it, because
we tried to disable the backup checkbox which did not exists
Signed-off-by: Dominik Csapak
---
this is a very simple workaround
since this inputpanel has to be reworked entirely,
for now this should be ok
www/manager6/lxc/ResourceEdit.js | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/www/manager6/lxc/ResourceEdit.js b/www/manager6/lxc/ResourceEdit.js
index dcf85f6e..c2e1f181 100644
--- a/www/manager6/lxc/ResourceEdit.js
+++ b/www/manager6/lxc/ResourceEdit.js
@@ -285,9 +285,11 @@ Ext.define('PVE.lxc.MountPointInputPanel', {
me.quota.setDisabled(true);
me.quota.setValue(false);
me.acl.setDisabled(true);
- me.backup.setDisabled(true);
me.acl.setValue('Default');
me.hdstoragesel.setDisabled(true);
+ if (me.confid !== 'rootfs') {
+ me.backup.setDisabled(true);
+ }
}
if (mp.replicate) { // check box reverses the config option
@@ -391,8 +393,10 @@ Ext.define('PVE.lxc.MountPointInputPanel', {
me.quota.setDisabled(true);
me.quota.setValue(false);
me.acl.setDisabled(true);
- me.backup.setDisabled(true);
me.acl.setValue('Default');
+ if (!isroot) {
+ me.backup.setDisabled(true);
+ }
return;
}
var rec = f.store.getById(value);
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH manager 3/3] check if storage is in the selector
when having an lxc mountpoint/rootfs on a storage which does not
allow the 'rootfs' content (e.g. somebody disabled it after creating
a container there), trying to edit the mp/rootfs broke the gui
now we check if the record exists
Signed-off-by: Dominik Csapak
---
this is also a very rough and simple workaround,
but again, this whole component needs to be reworked
www/manager6/lxc/ResourceEdit.js | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/www/manager6/lxc/ResourceEdit.js b/www/manager6/lxc/ResourceEdit.js
index c2e1f181..9efb5116 100644
--- a/www/manager6/lxc/ResourceEdit.js
+++ b/www/manager6/lxc/ResourceEdit.js
@@ -400,8 +400,9 @@ Ext.define('PVE.lxc.MountPointInputPanel', {
return;
}
var rec = f.store.getById(value);
- if (rec.data.type === 'zfs' ||
- rec.data.type === 'zfspool') {
+ if (rec &&
+ (rec.data.type === 'zfs' ||
+ rec.data.type === 'zfspool')) {
me.quota.setDisabled(true);
me.quota.setValue(false);
} else {
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH manager 1/3] fix wrong osd calculation in ceph dashboard
in luminous, the error message is not
'x/y in osds are down' anymore, but
'x osds down'
so we need to adapt the parsing, and it means we cannot check
the number of in osds there anymore (was never really needed, so
we can simply omit it)
when an osd is down but marked as out, those errors disappear
Signed-off-by: Dominik Csapak
---
www/manager6/ceph/StatusDetail.js | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/www/manager6/ceph/StatusDetail.js
b/www/manager6/ceph/StatusDetail.js
index 6517ab7b..f807674e 100644
--- a/www/manager6/ceph/StatusDetail.js
+++ b/www/manager6/ceph/StatusDetail.js
@@ -127,18 +127,13 @@ Ext.define('PVE.ceph.StatusDetail', {
var out_osds = total_osds - in_osds;
var down_osds = total_osds - up_osds;
var downin_osds = 0;
- var downinregex = /(\d+)\/(\d+) in osds are down/;
+ var downinregex = /(\d+) osds down/;
Ext.Array.some(record.data.health.summary, function(item) {
var found = item.summary.match(downinregex);
if (found !== null) {
- // sanity check, test if the message is
- // consistent with the direct value
- // for in osds
- if (found[2] == in_osds) {
downin_osds = parseInt(found[1],10);
return true;
- }
}
return false;
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH docs 2/2] correct calendar event examples
applied ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH docs 1/2] clarify example of calendar event
applied ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] applied: [PATCH manager v2 0/3] Refactor Qemu Create Wizard
applied ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
