> From: Zhu, Lingshan <lingshan.zhu@xxxxxxxxx> > 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 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
