On 9/28/22 18:03, Thomas Monjalon wrote:
28/09/2022 17:21, Claudio Fontana:
On 9/28/22 16:37, Maxime Coquelin wrote:
The title should be reworded, maybe something like below?
"vhost: fix possible out of bound access in buffer vectors"
possible, I leave it to you and other maintainers here now to figure out.
Maxime is suggesting a reword to you for your next version.
On 8/2/22 02:49, Claudio Fontana wrote:
[...]
This should fix errors that have been reported in multiple occasions
from telcos to the DPDK, OVS and QEMU projects, as this affects in
particular the openvswitch/DPDK, QEMU vhost-user setup when the
guest DPDK application abruptly goes away via SIGKILL and then
reconnects.
What are the "multiple occasions"? Is there an entry in bugs.dpdk.org?
[...]
I'm going to try to reproduce the issue, but I'm not sure I will
succeed. Could you please share the Vhost logs when the issue is
reproduced and you face the crash?
With vacations and lab work it's unlikely anything can be done from my side for
the next 2-3 weeks.
We can probably wait 3 more weeks.
Yes please, because I fail to reproduce it (Fc35 on host, Ubuntu 18.05
in guest).
What I can see is that on guest testpmd crash, the host backend receives
VHOST_USER_GET_VRING_BASE requests that stop the vring processing. on
reconnect, the rings start to be processed only when it received all the
configuration requests from QEMU.
Note that I have tested it with VFIO in the guest because I could not
find the uio_pci_generic module in Ubuntu 18.04 cloud image.
This issue has been reported multiple times from multiple telco customers for
about a year, it's all over the mailing lists
between ovs, dpdk and qemu, with all the details.
What was the reply on the DPDK mailing list? Any link?
Please provide the links, it may help to understand the root cause if
these mail threads contain logs.
Something in the governance of these Open Source projects is clearly not
working right, probably too much inward-focus between a small number of
companies, but I digress.
Contributors to DPDK are from multiple companies,
but I agree we may need more help.
Thank you for bringing your help with this fix.
I think Chenbo Xia already knows the context, and I suspect this is now considered a
"security issue". The problem is, the information about all of this has been
public already for a year.
OK
I will again repost how to reproduce here:
Thanks it helps to have all infos in the same place.
[...]
It is a fix, so it should contains the Fixes tag, and also cc
sta...@dpdk.org.
After one year, it is time for Redhat and Intel or whatever the governance of
this project is,
The DPDK governance is not owned by any company.
If you think there is an issue in a decision,
you can alert the Technical Board at techbo...@dpdk.org.
to mention if there is any intention to fix this or not,
before I or anyone else at SUSE will invest any more of our time and efforts
here.
I don't understand why we would not fix any issue.
I think the project is quite dynamic and fixing issues,
I am sorry if you have a different opinion.
Any tags you need you can add as required.
It would be nice to add the tags as suggested in the next version.
The most important would be to know where the issue comes from.
If you can identify the original commit introducing the bug,
you can mark it with:
Fixes: <commit-sha1> ("<commit-title>")
This way, maintainers and users know where it should be backported.
If any question, feel free to ask, we are here to help.
Thanks for the effort
