Re: [PATCH 3/3] scsi: storvsc: Validate length of incoming packet in storvsc_on_channel_callback()

On Thu, Dec 17, Andrea Parri (Microsoft) wrote: > Check that the packet is of the expected size at least, don't copy data > past the packet. > + if (hv_pkt_datalen(desc) < sizeof(struct vstor_packet) - > + stor_device->vmscsi_size_delta) { > +

Re: [PATCH v2] kbuild: enforce -Werror=unused-result

Am Fri, 26 Mar 2021 01:55:41 +0900 schrieb Masahiro Yamada : > What about drivers/net/ethernet/lantiq_etop.c ? Nothing complained about it. I guess there is a build-bot for alpha, but none for mips. > I got a lot of complaints in the last trial. Why did you get complains, instead of me?

Re: [PATCH v2] kbuild: enforce -Werror=unused-result

Am Fri, 19 Mar 2021 15:32:31 +0100 schrieb Olaf Hering : > It is a hard error if a return value is ignored. The automated builds found only a single error, in load_em86(). Let me know if there are other reasons why the patch was rejected. Olaf pgpwH6ihF0muQ.pgp Description: Digitale Signa

[PATCH v1] binfmt: check return value of remove_arg_zero

In preparation to build with -Werror=unused-result, use remove_arg_zero properly. Fixes commit b6a2fea39318e43fee84fa7b0b90d68bed92d2ba Signed-off-by: Olaf Hering --- fs/binfmt_em86.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/binfmt_em86.c b/fs/binfmt_em86.c

Re: [PATCH v2] tools/hv: async name resolution in kvp_daemon

Am Fri, 19 Mar 2021 15:41:44 +0100 schrieb Olaf Hering : > FullyQualifiedDomainName I think in the past I did asked MSFT what the host side really expects. Maybe this time there will be an answer. Why would the host expect a FQDN from a VM? Why would it care about DNS layout of the netw

[PATCH v2] tools/hv: async name resolution in kvp_daemon

answered with an empty string. Signed-off-by: Olaf Hering --- v2: resend, the thread aims for success. tools/hv/Makefile| 2 ++ tools/hv/hv_kvp_daemon.c | 69 ++-- 2 files changed, 48 insertions(+), 23 deletions(-) diff --git a/tools/hv/Make

[PATCH v2] kbuild: enforce -Werror=unused-result

It is a hard error if a return value is ignored. In case the return value has no meaning, remove the attribute. Signed-off-by: Olaf Hering --- v2: resend Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index a28bb374663d..9b7def6db494 100644

[PATCH v1] kbuild: enforce -Werror=unused-result

It is a hard error if a return value is ignored. In case the return value has no meaning, remove the attribute. Signed-off-by: Olaf Hering --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index e2c3f65c4721..c7f9acffad42 100644 --- a/Makefile

[PATCH v1] video: hyperv_fb: include vmalloc.h

hvfb_getmem uses vzalloc, therefore vmalloc.h should be included. Fixes commit d21987d709e807ba7bbf47044deb56a3c02e8be4 ("video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver") Signed-off-by: Olaf Hering --- drivers/video/fbdev/hyperv_fb.c | 1 + 1 file

Re: [PATCH v1] hv_balloon: disable warning when floor reached

Am Mon, 19 Oct 2020 02:58:08 + schrieb Michael Kelley : > I think we should take the patch. Thanks. I just briefly looked at the code, did not understand much of it. But it feels like the math uses the wrong input. I think its is not the 'pr_warn' that needs changing, the 'Fixes' tag would

Re: [PATCH v1] hv_balloon: disable warning when floor reached

Am Tue, 13 Oct 2020 11:19:21 +0200 schrieb Olaf Hering : > A message is generated every 5 minutes. Unclear why this remained unnoticed > since at least v5.3. I have added debug to my distro kernel to see what the > involved variable values are. More info later today. The actu

Re: [PATCH v1] hv_balloon: disable warning when floor reached

Am Tue, 13 Oct 2020 09:17:17 + schrieb Wei Liu : > So ... this patch is not needed anymore? Why? A message is generated every 5 minutes. Unclear why this remained unnoticed since at least v5.3. I have added debug to my distro kernel to see what the involved variable values are. More info

[PATCH v2] kbuild: enforce -Werror=return-type

Catch errors which at least gcc tolerates by default: warning: 'return' with no value, in function returning non-void [-Wreturn-type] Signed-off-by: Olaf Hering --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index f84d7e4ca0be..965e7259e6e8

Re: [PATCH v1] hv_balloon: disable warning when floor reached

Am Thu, 8 Oct 2020 09:12:15 +0200 schrieb Olaf Hering : > warning is logged in dmesg Actually it is logged on the system console, depending on how logging is configured. Olaf pgpdjkpjAh1xK.pgp Description: Digitale Signatur von OpenPGP

[PATCH v1] hv_balloon: disable warning when floor reached

It is not an error if a the host requests to balloon down, but the VM refuses to do so. Without this change a warning is logged in dmesg every five minutes. Fixes commit b3bb97b8a49f3 Signed-off-by: Olaf Hering --- drivers/hv/hv_balloon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion

[PATCH v1] kbuild: enforce -Werror=return-type

Catch errors which at least gcc tolerates by default: warning: 'return' with no value, in function returning non-void [-Wreturn-type] Signed-off-by: Olaf Hering --- Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Makefile b/Makefile index f84d7e4ca0be..7b2e63e7be18 100644

[PATCH v1] tools: hv: remove cast from hyperv_die_event

No need to cast a void pointer. Signed-off-by: Olaf Hering --- drivers/hv/vmbus_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c index 910b6e90866c..187809977360 100644 --- a/drivers/hv/vmbus_drv.c +++ b/drivers/hv

Re: [PATCH] Drivers: hv: Change flag to write log level in panic msg to false

On Fri, Jun 26, Joseph Salisbury wrote: > When the kernel panics, one page worth of kmsg data is written to an allocated > page. The Hypervisor is notified of the page address trough the MSR. This > panic information is collected on the host. Since we are only collecting one > page of data,

Re: recalibrating x86 TSC during suspend/resume

On Fri, Feb 22, Paolo Bonzini wrote: > On 22/02/19 12:44, Thomas Gleixner wrote: > >> The specific usecase I have is a workload within VMs that makes heavy > >> use of TSC. The kernel is booted with 'clocksource=tsc highres=off > >> nohz=off' > >> because only this clocksource gives enough

Re: recalibrating x86 TSC during suspend/resume

Am Fri, 22 Feb 2019 12:44:39 +0100 (CET) schrieb Thomas Gleixner : > Whether that is accurate enough or not to make NTP happy, I can't tell, but > it's definitely worth a try. Thanks Thomas, I will look into the suggestions. Olaf pgpKvKEGb9vSF.pgp Description: Digitale Signatur von OpenPGP

recalibrating x86 TSC during suspend/resume

Is there a way to recalibrate the x86 TSC during a suspend/resume cycle? While the frequency will remain the same on a Laptop, it may (or rather: it definitly will) differ if a VM is migrated from one host to another. The hypervisor may choose to emulate the expected TSC frequency on the

Re: [PATCH V3 2/3] HYPERV/IOMMU: Add Hyper-V stub IOMMU driver

On Thu, Feb 07, lantianyu1...@gmail.com wrote: > +++ b/drivers/iommu/Kconfig > +config HYPERV_IOMMU > + bool "Hyper-V x2APIC IRQ Handling" > + depends on HYPERV > + select IOMMU_API > + help Consider adding 'default HYPERV' like some other drivers already do it. Olaf

Re: [PATCH V2 3/4] vmbus: add per-channel sysfs info

Am Sun, 17 Sep 2017 20:54:18 -0700 schrieb k...@exchange.microsoft.com: > This extends existing vmbus related sysfs structure to provide per-channel > state information. This is useful when diagnosing issues with multiple > queues in networking and storage. > +++ b/drivers/hv/vmbus_drv.c >

Re: [PATCH V2 3/4] vmbus: add per-channel sysfs info

Am Sun, 17 Sep 2017 20:54:18 -0700 schrieb k...@exchange.microsoft.com: > This extends existing vmbus related sysfs structure to provide per-channel > state information. This is useful when diagnosing issues with multiple > queues in networking and storage. > +++ b/drivers/hv/vmbus_drv.c >

[PATCH v1] tools: hv: update lsvmbus to be compatible with python3

From: Olaf Hering <oher...@suse.de> Python3 changed the way how 'print' works. Adjust the code to a syntax that is understood by python2 and python3. Signed-off-by: Olaf Hering <oher...@suse.de> --- tools/hv/lsvmbus | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-)

[PATCH v1] tools: hv: update lsvmbus to be compatible with python3

From: Olaf Hering Python3 changed the way how 'print' works. Adjust the code to a syntax that is understood by python2 and python3. Signed-off-by: Olaf Hering --- tools/hv/lsvmbus | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/tools/hv/lsvmbus b/tools/hv

[PATCH v2] tools: hv: update lsvmbus to be compatible with python3

Python3 changed the way how 'print' works. Adjust the code to a syntax that is understood by python2 and python3. Signed-off-by: Olaf Hering <o...@aepfle.de> --- v2: correct author tools/hv/lsvmbus | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/to

[PATCH v2] tools: hv: update lsvmbus to be compatible with python3

Python3 changed the way how 'print' works. Adjust the code to a syntax that is understood by python2 and python3. Signed-off-by: Olaf Hering --- v2: correct author tools/hv/lsvmbus | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/tools/hv/lsvmbus b/tools/hv

[PATCH] tools: hv: include string.h in hv_fcopy_daemon

The usage of strchr requires inclusion of string.h. Fixes: 0c38cda64aec ("tools: hv: remove unnecessary header files and netlink related code") Signed-off-by: Olaf Hering <o...@aepfle.de> --- tools/hv/hv_fcopy_daemon.c | 1 + 1 file changed, 1 insertion(+) diff

[PATCH] tools: hv: include string.h in hv_fcopy_daemon

The usage of strchr requires inclusion of string.h. Fixes: 0c38cda64aec ("tools: hv: remove unnecessary header files and netlink related code") Signed-off-by: Olaf Hering --- tools/hv/hv_fcopy_daemon.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/hv/hv_fcopy_daemon.c

Re: [PATCHv2] tools: hv: hv_set_ifconfig.sh double check before setting ip

On Fri, Dec 08, Eduardo Otubo wrote: > tools/hv/hv_set_ifconfig.sh | 45 > +++-- > 1 file changed, 43 insertions(+), 2 deletions(-) > +# let's wait for 3 minutes Was this codepath runtime tested? Last time this came up, the conclusion was that

Re: [PATCHv2] tools: hv: hv_set_ifconfig.sh double check before setting ip

On Fri, Dec 08, Eduardo Otubo wrote: > tools/hv/hv_set_ifconfig.sh | 45 > +++-- > 1 file changed, 43 insertions(+), 2 deletions(-) > +# let's wait for 3 minutes Was this codepath runtime tested? Last time this came up, the conclusion was that

Re: [PATCH] tools: hv: handle EINTR in hv_fcopy_daemon

On Tue, Sep 05, KY Srinivasan wrote: > Were you planning on sending a patch for this. No, not yet. I dont know how SA_RESTART works. Olaf signature.asc Description: PGP signature

Re: [PATCH] tools: hv: handle EINTR in hv_fcopy_daemon

On Tue, Sep 05, KY Srinivasan wrote: > Were you planning on sending a patch for this. No, not yet. I dont know how SA_RESTART works. Olaf signature.asc Description: PGP signature

Re: [PATCHv2] hv_set_ifconfig.sh double check before setting ip

On Mon, Aug 28, Eduardo Otubo wrote: > +sleep 30s; Was this runtime tested? Once this sleep(1) is done, HV_UTIL_TIMEOUT kicks in and the daemon dies. Olaf signature.asc Description: PGP signature

Re: [PATCHv2] hv_set_ifconfig.sh double check before setting ip

On Mon, Aug 28, Eduardo Otubo wrote: > +sleep 30s; Was this runtime tested? Once this sleep(1) is done, HV_UTIL_TIMEOUT kicks in and the daemon dies. Olaf signature.asc Description: PGP signature

Re: [PATCH] tools: hv: handle EINTR in hv_fcopy_daemon

On Fri, Aug 25, Vitaly Kuznetsov wrote: > Shall we request SA_RESTART with sigaction() in all three daemons instead? If that works better, probably yes. Olaf signature.asc Description: PGP signature

Re: [PATCH] tools: hv: handle EINTR in hv_fcopy_daemon

On Fri, Aug 25, Vitaly Kuznetsov wrote: > Shall we request SA_RESTART with sigaction() in all three daemons instead? If that works better, probably yes. Olaf signature.asc Description: PGP signature

[PATCH] Drivers: hv: fcopy: restore correct transfer length

slightly less than expected. Fix this by restoring the expected buffer size in case of WRITE_TO_FILE. Fixes: c7e490fc23eb ("Drivers: hv: fcopy: convert to hv_utils_transport") Fixes: 3f2baa8a7d2e ("Tools: hv: update buffer handling in hv_fcopy_daemon") Signed-off-by: Olaf He

[PATCH] Drivers: hv: fcopy: restore correct transfer length

slightly less than expected. Fix this by restoring the expected buffer size in case of WRITE_TO_FILE. Fixes: c7e490fc23eb ("Drivers: hv: fcopy: convert to hv_utils_transport") Fixes: 3f2baa8a7d2e ("Tools: hv: update buffer handling in hv_fcopy_daemon") Signed-off-by: Olaf Her

[PATCH] tools: hv: handle EINTR in hv_fcopy_daemon

If strace attaches to the daemon pread returns with EINTR, and the process exits. Catch this case and continue with the next iteration. Signed-off-by: Olaf Hering <o...@aepfle.de> --- tools/hv/hv_fcopy_daemon.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/hv/hv_fcopy_daem

[PATCH] tools: hv: handle EINTR in hv_fcopy_daemon

If strace attaches to the daemon pread returns with EINTR, and the process exits. Catch this case and continue with the next iteration. Signed-off-by: Olaf Hering --- tools/hv/hv_fcopy_daemon.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/hv/hv_fcopy_daemon.c b/tools/hv

[PATCH RESEND] tools: hv: update buffer handling in hv_fcopy_daemon

members as needed. This also gives the correct size for the buffer (~6K instead of 64K). Signed-off-by: Olaf Hering <o...@aepfle.de> --- tools/hv/hv_fcopy_daemon.c | 31 --- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/tools/hv/hv_fcopy_daemon.c b/to

[PATCH RESEND] tools: hv: update buffer handling in hv_fcopy_daemon

members as needed. This also gives the correct size for the buffer (~6K instead of 64K). Signed-off-by: Olaf Hering --- tools/hv/hv_fcopy_daemon.c | 31 --- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/tools/hv/hv_fcopy_daemon.c b/tools/hv

[PATCH] Tools: hv: fix snprintf warning in kvp_daemon

Increase buffer size so that "_{-INT_MAX}" will fit. Spotted by the gcc7 snprintf checker. Signed-off-by: Olaf Hering <o...@aepfle.de> --- tools/hv/hv_kvp_daemon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kv

[PATCH] Tools: hv: fix snprintf warning in kvp_daemon

Increase buffer size so that "_{-INT_MAX}" will fit. Spotted by the gcc7 snprintf checker. Signed-off-by: Olaf Hering --- tools/hv/hv_kvp_daemon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c index 88

Re: 4.9.3, NULL pointer in __wake_up_common / drm / i915

On Thu, Dec 01, Olaf Hering wrote: > On Wed, Nov 16, Olaf Hering wrote: > > During boot into a current openSUSE Tumbleweed 20161108 this laptop > > starts to hang sometimes with 4.8.x. Today I was able to catch this > > crash in __wake_up_common caused by i9

Re: 4.9.3, NULL pointer in __wake_up_common / drm / i915

On Thu, Dec 01, Olaf Hering wrote: > On Wed, Nov 16, Olaf Hering wrote: > > During boot into a current openSUSE Tumbleweed 20161108 this laptop > > starts to hang sometimes with 4.8.x. Today I was able to catch this > > crash in __wake_up_common caused by i9

Re: [PATCH RFC] hv_utils: implement Hyper-V PTP source

On Fri, Jan 13, Vitaly Kuznetsov wrote: > + hv_ptp_clock = ptp_clock_register(_hyperv_info, NULL); > + if (IS_ERR(hv_ptp_clock)) { Should that be IS_ERR_OR_NULL to catch "!IS_REACHABLE(CONFIG_PTP_1588_CLOCK)"? Olaf signature.asc Description: PGP signature

Re: [PATCH RFC] hv_utils: implement Hyper-V PTP source

On Fri, Jan 13, Vitaly Kuznetsov wrote: > + hv_ptp_clock = ptp_clock_register(_hyperv_info, NULL); > + if (IS_ERR(hv_ptp_clock)) { Should that be IS_ERR_OR_NULL to catch "!IS_REACHABLE(CONFIG_PTP_1588_CLOCK)"? Olaf signature.asc Description: PGP signature

Re: [PATCH 03/15] hyperv: use standard bitops

On Tue, Dec 20, Roman Kagan wrote: Reverting commit 22356585712d ("staging: hv: use sync_bitops when interacting with the hypervisor") is save because ... > - sync_set_bit(channel->monitor_bit, > + set_bit(channel->monitor_bit, Olaf signature.asc Description: PGP

Re: [PATCH 03/15] hyperv: use standard bitops

On Tue, Dec 20, Roman Kagan wrote: Reverting commit 22356585712d ("staging: hv: use sync_bitops when interacting with the hypervisor") is save because ... > - sync_set_bit(channel->monitor_bit, > + set_bit(channel->monitor_bit, Olaf signature.asc Description: PGP

Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

On Thu, Dec 15, Vitaly Kuznetsov wrote: > -> K. Y., but these words were written before I implemented > vmbus_wait_for_unload(), to me they just explain how we read messages. Another question for KY: In my testing, while busy-looping in vmbus_wait_for_unload, I see a few "message_type==1,

Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

On Thu, Dec 15, Vitaly Kuznetsov wrote: > -> K. Y., but these words were written before I implemented > vmbus_wait_for_unload(), to me they just explain how we read messages. Another question for KY: In my testing, while busy-looping in vmbus_wait_for_unload, I see a few "message_type==1,

Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

On Thu, Dec 15, Vitaly Kuznetsov wrote: > vmbus_wait_for_unload() may be receiving a message (not necessarily the > CHANNELMSG_UNLOAD_RESPONSE, we may see some other message) on the same > CPU it runs and in this case wrmsrl() makes sense. In other cases it > does nothing (neither good nor bad).

Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

On Thu, Dec 15, Vitaly Kuznetsov wrote: > vmbus_wait_for_unload() may be receiving a message (not necessarily the > CHANNELMSG_UNLOAD_RESPONSE, we may see some other message) on the same > CPU it runs and in this case wrmsrl() makes sense. In other cases it > does nothing (neither good nor bad).

Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

On Thu, Dec 15, Vitaly Kuznetsov wrote: > We actually need to read the reply and empty the message slot to make > unload happen. And reading on a different CPU may not work, see: > > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2016-December/097330.html Does the following

Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

On Thu, Dec 15, Vitaly Kuznetsov wrote: > We actually need to read the reply and empty the message slot to make > unload happen. And reading on a different CPU may not work, see: > > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2016-December/097330.html Does the following

Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

On Thu, Dec 15, Vitaly Kuznetsov wrote: > I see a number of minor but at least one major issue against such move: > At least for some Hyper-V versions (2012R2 for example) > CHANNELMSG_UNLOAD_RESPONSE is delivered to the CPU which initially sent > CHANNELMSG_REQUESTOFFERS and on kdump we may not

Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

On Thu, Dec 15, Vitaly Kuznetsov wrote: > I see a number of minor but at least one major issue against such move: > At least for some Hyper-V versions (2012R2 for example) > CHANNELMSG_UNLOAD_RESPONSE is delivered to the CPU which initially sent > CHANNELMSG_REQUESTOFFERS and on kdump we may not

Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

On Thu, Dec 15, Olaf Hering wrote: > On Thu, Dec 15, Vitaly Kuznetsov wrote: > > > I see a number of minor but at least one major issue against such move: > > At least for some Hyper-V versions (2012R2 for example) > > CHANNELMSG_UNLOAD_RESPONSE is delivered to the

Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

On Thu, Dec 15, Olaf Hering wrote: > On Thu, Dec 15, Vitaly Kuznetsov wrote: > > > I see a number of minor but at least one major issue against such move: > > At least for some Hyper-V versions (2012R2 for example) > > CHANNELMSG_UNLOAD_RESPONSE is delivered to the

Re: 4.8.12, crash in ext4, __d_lookup_rcu

On Mon, Dec 12, Olaf Hering wrote: > On Mon, Dec 12, Theodore Ts'o wrote: > > > What was going on at the time of the crash, and can you reproduce this? > > Its the 'rm -rf $dir/$oldbackup.N' at the end of each rsnapshot run. Also, the system was otherwise idle during th

Re: 4.8.12, crash in ext4, __d_lookup_rcu

On Mon, Dec 12, Theodore Ts'o wrote: > What was going on at the time of the crash, and can you reproduce this? Its the 'rm -rf $dir/$oldbackup.N' at the end of each rsnapshot run. I will try to reproduce it, see if it happens again during the hourly rsnapshot runs. So far I have not seen it with

Re: 4.8.12, crash in ext4, __d_lookup_rcu

On Mon, Dec 12, Olaf Hering wrote: > On Mon, Dec 12, Theodore Ts'o wrote: > > > What was going on at the time of the crash, and can you reproduce this? > > Its the 'rm -rf $dir/$oldbackup.N' at the end of each rsnapshot run. Also, the system was otherwise idle during th

Re: 4.8.12, crash in ext4, __d_lookup_rcu

On Mon, Dec 12, Theodore Ts'o wrote: > What was going on at the time of the crash, and can you reproduce this? Its the 'rm -rf $dir/$oldbackup.N' at the end of each rsnapshot run. I will try to reproduce it, see if it happens again during the hourly rsnapshot runs. So far I have not seen it with

Re: 4.8.12, crash in ext4, __d_lookup_rcu

On Mon, Dec 12, Olaf Hering wrote: > [197064.401309] RIP: 0010:[] [] > __d_lookup_rcu+0x67/0x180 ... and umount is not happy after that, which I think is expected: root@probook:~ # umount -v /BACKUP_OLH_1T ; dmsetup remove luks-feaf408d-3257-4850-b597-bbca1dc651df ; sync ; bl

Re: 4.8.12, crash in ext4, __d_lookup_rcu

On Mon, Dec 12, Olaf Hering wrote: > [197064.401309] RIP: 0010:[] [] > __d_lookup_rcu+0x67/0x180 ... and umount is not happy after that, which I think is expected: root@probook:~ # umount -v /BACKUP_OLH_1T ; dmsetup remove luks-feaf408d-3257-4850-b597-bbca1dc651df ; sync ; bl

4.8.12, crash in ext4, __d_lookup_rcu

This crash happend during rsnapshot cleanup, full dmesg below: Dec 11 17:15:02 probook rsnapshot-backup-scripts.hourly.sh[3244]: claimed rsnapshot_pid_lock Dec 11 17:15:02 probook rsnapshot-backup-scripts.hourly.sh[3247]: running hourly ... [197064.399173] general protection fault: [#1]

4.8.12, crash in ext4, __d_lookup_rcu

This crash happend during rsnapshot cleanup, full dmesg below: Dec 11 17:15:02 probook rsnapshot-backup-scripts.hourly.sh[3244]: claimed rsnapshot_pid_lock Dec 11 17:15:02 probook rsnapshot-backup-scripts.hourly.sh[3247]: running hourly ... [197064.399173] general protection fault: [#1]

Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

On Wed, Dec 07, KY Srinivasan wrote: > May be a better solution might be to have a new mechanism to indicate > to the host that all state of the previous incarnation of the kernel > needs to be cleaned up. This will be close to what we have on > hardware. That would be cool, but until this

Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

On Wed, Dec 07, KY Srinivasan wrote: > May be a better solution might be to have a new mechanism to indicate > to the host that all state of the previous incarnation of the kernel > needs to be cleaned up. This will be close to what we have on > hardware. That would be cool, but until this

Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

On Wed, Dec 07, KY Srinivasan wrote: > Is there a mechanism for stashing away state that can be retrieved in > the context of the execed kernel. I have to find out. To simplify things the new approach may only be used in the kdump case, which already passes various info in cmdline. Most likely

Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

On Wed, Dec 07, KY Srinivasan wrote: > Is there a mechanism for stashing away state that can be retrieved in > the context of the execed kernel. I have to find out. To simplify things the new approach may only be used in the kdump case, which already passes various info in cmdline. Most likely

RE: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

Am 7. Dezember 2016 16:04:29 MEZ, schrieb KY Srinivasan : >Yes; I had played with this approach a while ago. The issue is that the >host knows about a >bunch of in memory state that will be different in the kexec kernel. >For instance if we did all >the cleanup as part of the

RE: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

Am 7. Dezember 2016 16:04:29 MEZ, schrieb KY Srinivasan : >Yes; I had played with this approach a while ago. The issue is that the >host knows about a >bunch of in memory state that will be different in the kexec kernel. >For instance if we did all >the cleanup as part of the boot sequence, we

move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

KY, if a hyperv VM crashes alot of work must be done to prepare the environment for the kdump kernel. This approach is different compared to all the other VM types, or baremetal. Since the just crashed kernel is per definition unreliable all that work should be done within the kdump kernel

move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

KY, if a hyperv VM crashes alot of work must be done to prepare the environment for the kdump kernel. This approach is different compared to all the other VM types, or baremetal. Since the just crashed kernel is per definition unreliable all that work should be done within the kdump kernel

Re: 4.8.6, NULL pointer in __wake_up_common / drm / i915

On Wed, Nov 16, Olaf Hering wrote: > During boot into a current openSUSE Tumbleweed 20161108 this laptop > starts to hang sometimes with 4.8.x. Today I was able to catch this > crash in __wake_up_common caused by i915 or drm or whatever: > > ... > [ 69.851635] BUG: unabl

Re: 4.8.6, NULL pointer in __wake_up_common / drm / i915

On Wed, Nov 16, Olaf Hering wrote: > During boot into a current openSUSE Tumbleweed 20161108 this laptop > starts to hang sometimes with 4.8.x. Today I was able to catch this > crash in __wake_up_common caused by i915 or drm or whatever: > > ... > [ 69.851635] BUG: unabl

Re: [PATCH v4] xen/gntdev: Use VM_MIXEDMAP instead of VM_IO to avoid NUMA balancing

On Mon, Nov 21, Boris Ostrovsky wrote: > Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to > NUMA balancing") set VM_IO flag to prevent grant maps from being > subjected to NUMA balancing. Tested-by: Olaf Hering <o...@aepfle.de> This should go

Re: [PATCH v4] xen/gntdev: Use VM_MIXEDMAP instead of VM_IO to avoid NUMA balancing

On Mon, Nov 21, Boris Ostrovsky wrote: > Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to > NUMA balancing") set VM_IO flag to prevent grant maps from being > subjected to NUMA balancing. Tested-by: Olaf Hering This should go to stable as well. O

Re: [PATCH v3 (re-send)] xen/gntdev: Use mempolicy instead of VM_IO flag to avoid NUMA balancing

On Thu, Nov 17, Boris Ostrovsky wrote: > Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to > NUMA balancing") set VM_IO flag to prevent grant maps from being > subjected to NUMA balancing. Thanks, this works for me in 4.4: Tested-by: Olaf Hering <

Re: [PATCH v3 (re-send)] xen/gntdev: Use mempolicy instead of VM_IO flag to avoid NUMA balancing

On Thu, Nov 17, Boris Ostrovsky wrote: > Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to > NUMA balancing") set VM_IO flag to prevent grant maps from being > subjected to NUMA balancing. Thanks, this works for me in 4.4: Tested-by: Olaf Hering O

Re: [PATCH v2] xen/gntdev: Use mempolicy instead of VM_IO flag to avoid NUMA balancing

On Thu, Nov 17, Boris Ostrovsky wrote: > On 11/17/2016 06:28 AM, Olaf Hering wrote: > > ERROR: "__mpol_dup" [drivers/xen/xen-gntdev.ko] undefined! > > ERROR: "get_task_policy" [drivers/xen/xen-gntdev.ko] undefined! > I just built 4.4.11 with this patc

Re: [PATCH v2] xen/gntdev: Use mempolicy instead of VM_IO flag to avoid NUMA balancing

On Thu, Nov 17, Boris Ostrovsky wrote: > On 11/17/2016 06:28 AM, Olaf Hering wrote: > > ERROR: "__mpol_dup" [drivers/xen/xen-gntdev.ko] undefined! > > ERROR: "get_task_policy" [drivers/xen/xen-gntdev.ko] undefined! > I just built 4.4.11 with this patc

Re: [PATCH v2] xen/gntdev: Use mempolicy instead of VM_IO flag to avoid NUMA balancing

On Wed, Nov 16, Boris Ostrovsky wrote: > Unfortunately I haven't been able to trigger NUMA balancing > so while I tested this in general I am not sure I actually > exercised the code path. Thanks for the patch! Would be nice to actually test the code path which caused the initial addition of

Re: [PATCH v2] xen/gntdev: Use mempolicy instead of VM_IO flag to avoid NUMA balancing

On Wed, Nov 16, Boris Ostrovsky wrote: > Unfortunately I haven't been able to trigger NUMA balancing > so while I tested this in general I am not sure I actually > exercised the code path. Thanks for the patch! Would be nice to actually test the code path which caused the initial addition of

4.8.6, NULL pointer in __wake_up_common / drm / i915

During boot into a current openSUSE Tumbleweed 20161108 this laptop starts to hang sometimes with 4.8.x. Today I was able to catch this crash in __wake_up_common caused by i915 or drm or whatever: ... [ 69.851635] BUG: unable to handle kernel NULL pointer dereference at (null) [

4.8.6, NULL pointer in __wake_up_common / drm / i915

During boot into a current openSUSE Tumbleweed 20161108 this laptop starts to hang sometimes with 4.8.x. Today I was able to catch this crash in __wake_up_common caused by i915 or drm or whatever: ... [ 69.851635] BUG: unable to handle kernel NULL pointer dereference at (null) [

Re: [Xen-devel] [PATCH RESEND] xen/gntdev: Grant maps should not be subject to NUMA balancing

On Thu, Nov 10, Boris Ostrovsky wrote: > Are you sure it's this patch that causes the failure? > > I commented out '| VM_IO' and still unable to boot with this option. Yes, this works for me, sles12sp2 dom0+domU, which is linux-4.4 based: +++ b/drivers/xen/gntdev.c @@ -804,7 +804,7 @@ static

Re: [Xen-devel] [PATCH RESEND] xen/gntdev: Grant maps should not be subject to NUMA balancing

On Thu, Nov 10, Boris Ostrovsky wrote: > Are you sure it's this patch that causes the failure? > > I commented out '| VM_IO' and still unable to boot with this option. Yes, this works for me, sles12sp2 dom0+domU, which is linux-4.4 based: +++ b/drivers/xen/gntdev.c @@ -804,7 +804,7 @@ static

Re: [Xen-devel] [PATCH RESEND] xen/gntdev: Grant maps should not be subject to NUMA balancing

On Thu, Nov 10, Boris Ostrovsky wrote: > Is this something new? Because this patch has been there for a year. It was just tested now, cycling through all the combinations for a disk=[]. Removing "direct-is-save" will use different code paths and the error is not seen. Olaf signature.asc

Re: [Xen-devel] [PATCH RESEND] xen/gntdev: Grant maps should not be subject to NUMA balancing

On Thu, Nov 10, Boris Ostrovsky wrote: > Is this something new? Because this patch has been there for a year. It was just tested now, cycling through all the combinations for a disk=[]. Removing "direct-is-save" will use different code paths and the error is not seen. Olaf signature.asc

Re: [Xen-devel] [PATCH RESEND] xen/gntdev: Grant maps should not be subject to NUMA balancing

On Tue, Nov 10, Boris Ostrovsky wrote: > Doing so will cause the grant to be unmapped and then, during > fault handling, the fault to be mistakenly treated as NUMA hint > fault. > > In addition, even if those maps could partcipate in NUMA > balancing, it wouldn't provide any benefit since we are

Re: [Xen-devel] [PATCH RESEND] xen/gntdev: Grant maps should not be subject to NUMA balancing

On Tue, Nov 10, Boris Ostrovsky wrote: > Doing so will cause the grant to be unmapped and then, during > fault handling, the fault to be mistakenly treated as NUMA hint > fault. > > In addition, even if those maps could partcipate in NUMA > balancing, it wouldn't provide any benefit since we are

Re: [PATCH 1/1] Drivers: hv: hv_util: Avoid dynamic allocation in time synch

On Fri, Sep 09, k...@exchange.microsoft.com wrote: > + * This check is safe since we are executing in the > + * interrupt context and time synch messages arre always Typo. Olaf signature.asc Description: PGP signature

Re: [PATCH 1/1] Drivers: hv: hv_util: Avoid dynamic allocation in time synch

On Fri, Sep 09, k...@exchange.microsoft.com wrote: > + * This check is safe since we are executing in the > + * interrupt context and time synch messages arre always Typo. Olaf signature.asc Description: PGP signature

Re: [PATCH 3/3] Drivers: hv: utils: Support TimeSync version 4.0 protocol samples.

On Tue, Sep 13, Alex Ng (LIS) wrote: > > On Thu, Sep 08, k...@exchange.microsoft.com wrote: > > Perhaps a better approach would be to list the known existing hosts and use > > the new protocol for upcoming, unknown hosts via 'default:'. > This is a good idea. I will create another patch that

Re: [PATCH 3/3] Drivers: hv: utils: Support TimeSync version 4.0 protocol samples.

On Tue, Sep 13, Alex Ng (LIS) wrote: > > On Thu, Sep 08, k...@exchange.microsoft.com wrote: > > Perhaps a better approach would be to list the known existing hosts and use > > the new protocol for upcoming, unknown hosts via 'default:'. > This is a good idea. I will create another patch that

  1   2   3   4   5   6   7   8   9   10   >