On Thu, 21 Apr 2022 11:40:00 -0400 Ray Kinsella <m...@ashroe.eu> wrote:
> Stephen Hemminger <step...@networkplumber.org> writes: > > > On Thu, 21 Apr 2022 12:38:26 +0800 > > Stephen Coleman <omegacole...@gmail.com> wrote: > > > >> KNI ioctl functions copy data from userspace lib, and this interface > >> of kmod is not compatible indeed. If the user use incompatible rte_kni.ko > >> bad things happen: sometimes various fields contain garbage value, > >> sometimes it cause a kmod soft lockup. > >> > >> Some common distros ship their own rte_kni.ko, so this is likely to > >> happen. > >> > >> This patch add abi version checking between userland lib and kmod so > >> that: > >> > >> * if kmod ioctl got a wrong abi magic, it refuse to go on > >> * if userland lib, probed a wrong abi version via newly added ioctl, it > >> also refuse to go on > >> > >> Bugzilla ID: 998 > > > > > > Kernel API's are supposed to be 99% stable. > > If this driver was playing by the upstream kernel rules this would not > > have happened. > > Well look, it is out-of-tree and never likely to be in-tree, so those > rules don't apply. Making sure the ABI doesn't change during the ABI > stablity period, should be good enough? > I think if KNI changes, it should just add more ioctl numbers and be compatible, it is not that hard.
