[RFC,v2,0/9] vhost lock annotations

  vhost internals involves multiple locks to protect data access by
multiple threads.

This series is a try at using clang thread safety checks [1] to catch
issues during compilation: EAL spinlock and rwlock are annotated and
vhost code is instrumented so that clang can statically check
correctness.

This is still a work in progress (some documentation and a release note
update are missing).

Those annotations are quite heavy to maintain because the full path of
code must be annotated, but I think it is worth using.


1: https://clang.llvm.org/docs/ThreadSafetyAnalysis.html
  

On Wed, Mar 30, 2022 at 3:50 PM David Marchand
<david.marchand@redhat.com> wrote:
>
> vhost internals involves multiple locks to protect data access by
> multiple threads.
>
> This series is a try at using clang thread safety checks [1] to catch
> issues during compilation: EAL spinlock and rwlock are annotated and
> vhost code is instrumented so that clang can statically check
> correctness.
>
> This is still a work in progress (some documentation and a release note
> update are missing).
>
> Those annotations are quite heavy to maintain because the full path of
> code must be annotated, but I think it is worth using.
>
>
> 1: https://clang.llvm.org/docs/ThreadSafetyAnalysis.html

It looks like mimecast shot the first patch (which I sent in place of
Maxime, because this series should go through the main repo).

Looking at the mail source, I see:

X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation
Protection Definition;Similar Internal Domain=false;Similar Monitored
External Domain=false;Custom External Domain=false;Mimecast External
Domain=false;Newly Observed Domain=false;Internal User
Name=false;Custom Display Name List=false;Reply-to Address
Mismatch=false;Targeted Threat Dictionary=false;Mimecast Threat
Dictionary=false;Custom Threat Dictionary=false

I don't know how to understand this...
But as a result, the series is missing this patch in patchwork.
Patch 1 is still available from RFC v1:
https://patchwork.dpdk.org/project/dpdk/patch/20220328121758.26632-2-david.marchand@redhat.com/
or via next-virtio.
  

[..]
> It looks like mimecast shot the first patch (which I sent in place of
> Maxime, because this series should go through the main repo).
> 
> Looking at the mail source, I see:
> 
> X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation
> Protection Definition;Similar Internal Domain=false;Similar Monitored
> External Domain=false;Custom External Domain=false;Mimecast External
> Domain=false;Newly Observed Domain=false;Internal User
> Name=false;Custom Display Name List=false;Reply-to Address
> Mismatch=false;Targeted Threat Dictionary=false;Mimecast Threat
> Dictionary=false;Custom Threat Dictionary=false
> 
> I don't know how to understand this...
> But as a result, the series is missing this patch in patchwork.

I believe it was ignored by Patchwork because of its content-type (application/octet-stream), which indicates that the message contains binary data instead of text:
> Content-Transfer-Encoding: 8bit
> Content-Type: application/octet-stream; x-default=true

Regards,
Ali
  

On Wed, Mar 30, 2022 at 4:37 PM Ali Alnubani <alialnu@nvidia.com> wrote:
>
> [..]
> > It looks like mimecast shot the first patch (which I sent in place of
> > Maxime, because this series should go through the main repo).
> >
> > Looking at the mail source, I see:
> >
> > X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation
> > Protection Definition;Similar Internal Domain=false;Similar Monitored
> > External Domain=false;Custom External Domain=false;Mimecast External
> > Domain=false;Newly Observed Domain=false;Internal User
> > Name=false;Custom Display Name List=false;Reply-to Address
> > Mismatch=false;Targeted Threat Dictionary=false;Mimecast Threat
> > Dictionary=false;Custom Threat Dictionary=false
> >
> > I don't know how to understand this...
> > But as a result, the series is missing this patch in patchwork.
>
> I believe it was ignored by Patchwork because of its content-type (application/octet-stream), which indicates that the message contains binary data instead of text:
> > Content-Transfer-Encoding: 8bit
> > Content-Type: application/octet-stream; x-default=true

Probably the consequence of some Mimecast mangling.

I noticed similar issues in my inbox for some Luca mails on stable@
and some mails from @Intel people on dev@ and even on netdev@.
In all cases where From: contains a name != sender, my inbox got the
same "content stripped and attached" symptom.
On the other hand, those mails end up fine in public mail archives.

Looking at headers of publicly archived mails and comparing with what
I got, there is an additional trace of Mimecast between dpdk.org
server and my inbox.

I opened a IT ticket internally.
I hope it will get fixed quickly.