netdev - RE: [PATCH V3 3/6] vDPA: allow userspace to query features of a vDPA device

lists.openwall.net		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 <parav@...dia.com>
To:     "Zhu, Lingshan" <lingshan.zhu@...el.com>,
        Jason Wang <jasowang@...hat.com>,
        "mst@...hat.com" <mst@...hat.com>
CC:     "virtualization@...ts.linux-foundation.org" 
        <virtualization@...ts.linux-foundation.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "xieyongji@...edance.com" <xieyongji@...edance.com>,
        "gautam.dawar@....com" <gautam.dawar@....com>
Subject: RE: [PATCH V3 3/6] vDPA: allow userspace to query features of a vDPA
 device


> From: Zhu, Lingshan <lingshan.zhu@...el.com>
> 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
> name VDPA_ATTR_VDPA_DEV_SUPPORTED_FEATURES, it is more than
> welcome to suggest a new one
> 
> Thanks