Hi all,
I'm reporting two regressions following certain VMBus/VSCs hardening changes
we've been discussing 'recently', unfortunately the first regression already
touched/affects mainline while the second one is in hyperv-next:
1) [mainline]
The first regression manifests with the following message (several):
hv_vmbus: No request id available
I could reliably reproduce such message/behavior by running the command:
fio --name=seqwrite --rw=read --direct=1 --ioengine=libaio --bs=32k --numjobs=4 --size=2G --runtime=60
(the message is triggered when files are being created).
I've bisected this regression to commit:
453de21c2b8281 ("scsi: storvsc: Use vmbus_requestor to generate transaction IDs for VMBus hardening")
2) [hyperv-next]
The second regression manifests with various messages including:
hv_netvsc 9c5f5000-0499-4b18-b2eb-a8d5c57c8774 eth0: Unknown nvsp packet type received 51966
hv_netvsc 9c5f5000-0499-4b18-b2eb-a8d5c57c8774 eth0: unhandled packet type 0, tid 0
hv_netvsc 9c5f5000-0499-4b18-b2eb-a8d5c57c8774 eth0: Incorrect transaction id
hv_netvsc 9c5f5000-0499-4b18-b2eb-a8d5c57c8774 eth0: Invalid rndis_msg (buflen: 262, msg_len: 1728)
The connection was then typically lost/reset by the peer.
I could reproduce such behavior/messages by running the test:
ntttcp -r -m 8,*,<receiver IP address> # receiver
ntttcp -s -m 8,*,<receiver IP address> -ns -t 60 # sender
I bisected this regression to commit:
a8c3209998afb5 ("Drivers: hv: vmbus: Copy packets sent by Hyper-V out of the ring buffer")
---
I am investigating but don't have fixes for these regressions now: given the
'timing' (-rc7 with the next merge window at the door...) I would propose to
revert/drop the interested changes:
1) 453de21c2b8281 is part of the so called 'vmbus_requestor' series that was
applied during the merge window for 5.11:
e8b7db38449ac5 ("Drivers: hv: vmbus: Add vmbus_requestor data structure for VMBus hardening")
453de21c2b8281 ("scsi: storvsc: Use vmbus_requestor to generate transaction IDs for VMBus hardening")
4d18fcc95f5095 ("hv_netvsc: Use vmbus_requestor to generate transaction IDs for VMBus hardening")
I could prepare/submit patches to revert such commits (asap but likely not
before tomorrow/late Saturday - EU time).
2) IIUC a8c3209998afb5 could be dropped (after rebase) without further modi-
fications to hyperv-next.
Other suggestions/thoughts?
Thanks,
Andrea
On Fri, Feb 12, 2021 at 05:50:50PM +0100, Andrea Parri wrote:
> Hi all,
[...]
> 2) IIUC a8c3209998afb5 could be dropped (after rebase) without further modi-
> fications to hyperv-next.
I've reverted the said patch from hyperv-next.
Wei.