From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id E26A5A0093; Thu, 21 Apr 2022 17:51:03 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C359940042; Thu, 21 Apr 2022 17:51:03 +0200 (CEST) Received: from mail-pg1-f176.google.com (mail-pg1-f176.google.com [209.85.215.176]) by mails.dpdk.org (Postfix) with ESMTP id 87DF040040 for ; Thu, 21 Apr 2022 17:51:02 +0200 (CEST) Received: by mail-pg1-f176.google.com with SMTP id s137so4986650pgs.5 for ; Thu, 21 Apr 2022 08:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=rkFfx4DGf4tzpAEVASLv5KrtHWMDYVEHkmuJxjENtPo=; b=x9BZqK6SibowswFRRwfXXnftlmTuucay9zTa8fvIlL/f0pUvGETMplSLPcF2RCw4oB dtUGZvpn+v51GGhZd8y2tL48YnjlZU6oY58LX8eBZHbSrjtecC/LzT/oWir5glvuxHpo m1yjufF0ZKJ4D8uolshUA7UXLZHtyEM6EGpsOdXNVeDQnWWxSTqyuU737k1XP6sCNlIT D6qVh5sgeCJf35ZUiYHSMOSBpuBCqH0jc4Lhn7oSljZer+fAh36WE0lYU3L/DYHzX9X1 iZBHkxi097jSwzEYsQk7meDv9ggQLISZb/pvE+G2sGeqXMkW43Tbat94bjm+q7MO0Cs6 PB9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=rkFfx4DGf4tzpAEVASLv5KrtHWMDYVEHkmuJxjENtPo=; b=sfU6w1ODg71ARQjJh3B3w63ymIpGwU/F1DBaVQsL/VIYuo26+Nds3qpGmGKqj/vypi +Xx2DNuh8hOwZLBR5hh1P0eH776FZmQHPtpRCq1qTA1bptbHY0eB0wyOffbdvqXW0/FK PsWKOMNfhZjrrNQmS3FeP9UNIWSk4BOyko1FaX6TqmkA8Inl2UUeiIAAwdEGSwgPqQiU ihr3Kb6IfRVTTtKE+FbvQcZKjmzxhcoobQ8Vh3uutI3mCRzgazDsjnxz/3xCQKg0bYwS Aw6q2wsukA00I7i321rVIUOXvY7PYsIRZGVsrBUDv3OMeufv0aA8v21ereeG+3MXhg+Y 2wxw== X-Gm-Message-State: AOAM533oNshAwXSGWmeQb57as0yR8vzis8UJiXJehCHnsUX2QfBwVJeH xxnv0KksPdnrUViKLgk9La/vDQ== X-Google-Smtp-Source: ABdhPJwS7hi+mBJLCjiyINuA72axS8zKVBYg6Id5FB3W2xHgIHBBDt5nZuJ45i0wH4ohCGCCRQwGsw== X-Received: by 2002:a65:47c4:0:b0:39d:4f85:40e0 with SMTP id f4-20020a6547c4000000b0039d4f8540e0mr64391pgs.309.1650556261604; Thu, 21 Apr 2022 08:51:01 -0700 (PDT) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id d6-20020a056a00244600b004f701135460sm25639542pfj.146.2022.04.21.08.51.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Apr 2022 08:51:01 -0700 (PDT) Date: Thu, 21 Apr 2022 08:50:58 -0700 From: Stephen Hemminger To: Ray Kinsella Cc: Stephen Coleman , dev@dpdk.org, Ferruh Yigit Subject: Re: kni: check abi version between kmod and lib Message-ID: <20220421085058.60119998@hermes.local> In-Reply-To: <87czhao373.fsf@mdr78.vserver.site> References: <20220421075444.6f872836@hermes.local> <87czhao373.fsf@mdr78.vserver.site> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Thu, 21 Apr 2022 11:40:00 -0400 Ray Kinsella wrote: > Stephen Hemminger writes: > > > On Thu, 21 Apr 2022 12:38:26 +0800 > > Stephen Coleman 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.