lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 5 Jul 2022 17:01:24 +0000
From:   Parav Pandit <>
To:     "Zhu, Lingshan" <>,
        Jason Wang <>,
        "" <>
CC:     "" 
        "" <>,
        "" <>,
        "" <>
Subject: RE: [PATCH V3 3/6] vDPA: allow userspace to query features of a vDPA

> From: Zhu, Lingshan <>
> Sent: Tuesday, July 5, 2022 12:56 PM
> > Both can be queried simultaneously. Each will return their own feature bits
> using same attribute.
> > It wont lead to the race.
> How? It is just a piece of memory, xxxx[attr], do you see locks in
> nla_put_u64_64bit()? It is a typical race condition, data accessed by multiple
> producers / consumers.
No. There is no race condition in here.
And new attribute enum by no means avoid any race.

Data put using nla_put cannot be accessed until they are transferred.

> And re-use a netlink attr is really confusing.
Please put comment for this variable explaining why it is shared for the exception.

Before that lets start, can you share a real world example of when this feature bitmap will have different value than the mgmt. device bitmap value?

> >
> >> IMHO, I don't see any advantages of re-using this attr.
> > We don’t want to continue this mess of VDPA_DEV prefix for new
> attributes due to previous wrong naming.
> as you point out before, is is a wrong naming, we can't re-nmme it because
> we don't want to break uAPI, so there needs a new attr, if you don't like the
> welcome to suggest a new one
> Thanks

Powered by blists - more mailing lists