| Message ID | 20200427231625.10135-1-stephen@networkplumber.org (mailing list archive) |
|---|---|
| Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2B30AA00BE; Tue, 28 Apr 2020 01:16:36 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A38D21D50E; Tue, 28 Apr 2020 01:16:35 +0200 (CEST) Received: from mail-pg1-f196.google.com (mail-pg1-f196.google.com [209.85.215.196]) by dpdk.org (Postfix) with ESMTP id 866861D452 for <dev@dpdk.org>; Tue, 28 Apr 2020 01:16:34 +0200 (CEST) Received: by mail-pg1-f196.google.com with SMTP id x26so9391418pgc.10 for <dev@dpdk.org>; Mon, 27 Apr 2020 16:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=1XjLtrwrd7or9iNQMLFhZHCJhths9DVtRBncjKFG/Ug=; b=mftV9e4nSKFLsk/CwsaXD6bN1YKDwjMdRf7dtCvvNtAkxA+xwNz1WuTUPEtEhv9dSP fYdTQRI7PQy/vyG050eOLDO6f6QvnZbe+684ht4B8xWHAUcQoSUs1cgBrtI63qlBSVHG CZCOsul2Rtwn7bH7Y+Eo4MmQ7xnBxszk5aqGBnqKj1TR9W6uMg+lMxonuywfYdQWC79u 1jNxFKwB8p7LBiZ7DvZhAT+RpCRW0GoRmIy19GJn6g8w1mujN8ykp0xULsLagtha/e8e DaddwjbpDH3AolgDUw3k2jNbhzyDjz0E1zOqX8VZx3KQj1UZH9Sern+kk5VbaRNm53n3 eNdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=1XjLtrwrd7or9iNQMLFhZHCJhths9DVtRBncjKFG/Ug=; b=sNsIrePpK5G2T1vHik+2aENxwWa1RZlfzxqVzMWVk7ljsfHWMdJHWIVn83vdvh/k1H NlzHCm3q2Gi/Slilkm9oqdKG2r/TlaDyMzIU1oXs9kVBPlb4YHY18wVgWvuNqh24Eqaq O+Cyqw1rG5Xv/SBF4Dt0Dyp9fftJdNSxjTFNUn2GmtrbNlF0Dl8WHxyM9uzxddmJ5gjF 3AwVLF4WO8N42Y4qYBcUDyZy01AsPwl04QlebkhvRZXO0ZXyqSmxKEc1jXh0B6CA+dL5 pf7O2wslwH9S+32PvYnerGv0SzUk7/p1bMav4PfN8xlx+Wk9bAC9h2If4C8Xd6qOGKEN nFog== X-Gm-Message-State: AGi0PuagZrNK9Ue4+SMw5/jsDFFQs8wHd2/Db4tlCGOv11N6SqHQQpJ3 gn2BIB3jTTuIZF1b3H7TwxWlg6gTQU4= X-Google-Smtp-Source: APiQypJSgEjczkRY2MQPkHQ7fPHuglMhUVWVC+uG+GME6+PAadeBRp5BDXPVMhaPWkQ44yiWtBJcjw== X-Received: by 2002:a63:ff49:: with SMTP id s9mr26079562pgk.46.1588029393264; Mon, 27 Apr 2020 16:16:33 -0700 (PDT) Received: from hermes.corp.microsoft.com (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id kb10sm353104pjb.6.2020.04.27.16.16.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Apr 2020 16:16:32 -0700 (PDT) From: Stephen Hemminger <stephen@networkplumber.org> To: dev@dpdk.org Cc: Stephen Hemminger <stephen@networkplumber.org> Date: Mon, 27 Apr 2020 16:16:21 -0700 Message-Id: <20200427231625.10135-1-stephen@networkplumber.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200212230810.2837-1-stephen@networkplumber.org> References: <20200212230810.2837-1-stephen@networkplumber.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [dpdk-dev] [PATCH v3 0/4] Enforce checking on flag values in API's X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
| Series |
Enforce checking on flag values in API's
|
|
Message
Stephen Hemminger
April 27, 2020, 11:16 p.m. UTC
The DPDK API's are lax about checking for undefined flag values. This makes it impossible to add new bits to existing API's without causing ABI breakage. This means we end up doing unnecessary symbol versioning just to work around applications that might pass in naughty bits. This is the DPDK analog of the Linux kernel openat() problem. Openat api was added but since kernel did not check flags it ended up that another syscall openat2() was necessary before the flags could be used. v3 - define mask based on existing defines for ring and hash Stephen Hemminger (4): ring: future proof flag settings hash: check flags on creation stack: check flags on creation cfgfile: check flags value lib/librte_cfgfile/rte_cfgfile.c | 4 ++++ lib/librte_hash/rte_cuckoo_hash.c | 14 ++++++++++++++ lib/librte_ring/rte_ring.c | 12 ++++++++++++ lib/librte_stack/rte_stack.c | 5 +++++ 4 files changed, 35 insertions(+)
Comments
On Mon, Apr 27, 2020 at 04:16:21PM -0700, Stephen Hemminger wrote: > The DPDK API's are lax about checking for undefined flag values. > This makes it impossible to add new bits to existing API's > without causing ABI breakage. This means we end up doing unnecessary > symbol versioning just to work around applications that might > pass in naughty bits. > > This is the DPDK analog of the Linux kernel openat() problem. > Openat api was added but since kernel did not check flags it > ended up that another syscall openat2() was necessary before > the flags could be used. > > v3 - define mask based on existing defines for ring and hash > > Stephen Hemminger (4): > ring: future proof flag settings > hash: check flags on creation > stack: check flags on creation > cfgfile: check flags value > > lib/librte_cfgfile/rte_cfgfile.c | 4 ++++ > lib/librte_hash/rte_cuckoo_hash.c | 14 ++++++++++++++ > lib/librte_ring/rte_ring.c | 12 ++++++++++++ > lib/librte_stack/rte_stack.c | 5 +++++ > 4 files changed, 35 insertions(+) > I think this is a good idea to do in DPDK Series-acked-by: Bruce Richardson <bruce.richardson@intel.com>
> The DPDK API's are lax about checking for undefined flag values. > This makes it impossible to add new bits to existing API's > without causing ABI breakage. This means we end up doing unnecessary > symbol versioning just to work around applications that might > pass in naughty bits. > > This is the DPDK analog of the Linux kernel openat() problem. > Openat api was added but since kernel did not check flags it > ended up that another syscall openat2() was necessary before > the flags could be used. > > v3 - define mask based on existing defines for ring and hash > > Stephen Hemminger (4): > ring: future proof flag settings > hash: check flags on creation > stack: check flags on creation > cfgfile: check flags value > > lib/librte_cfgfile/rte_cfgfile.c | 4 ++++ > lib/librte_hash/rte_cuckoo_hash.c | 14 ++++++++++++++ > lib/librte_ring/rte_ring.c | 12 ++++++++++++ > lib/librte_stack/rte_stack.c | 5 +++++ > 4 files changed, 35 insertions(+) > > -- Series Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com> > 2.20.1
28/04/2020 12:28, Bruce Richardson: > On Mon, Apr 27, 2020 at 04:16:21PM -0700, Stephen Hemminger wrote: > > The DPDK API's are lax about checking for undefined flag values. > > This makes it impossible to add new bits to existing API's > > without causing ABI breakage. This means we end up doing unnecessary > > symbol versioning just to work around applications that might > > pass in naughty bits. > > > > This is the DPDK analog of the Linux kernel openat() problem. > > Openat api was added but since kernel did not check flags it > > ended up that another syscall openat2() was necessary before > > the flags could be used. > > > > v3 - define mask based on existing defines for ring and hash > > > > Stephen Hemminger (4): > > ring: future proof flag settings > > hash: check flags on creation > > stack: check flags on creation > > cfgfile: check flags value > > > I think this is a good idea to do in DPDK > > Series-acked-by: Bruce Richardson <bruce.richardson@intel.com> Applied, thanks