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 3A274A034F; Sat, 9 Oct 2021 04:03:41 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 87CC340685; Sat, 9 Oct 2021 04:03:40 +0200 (CEST) Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) by mails.dpdk.org (Postfix) with ESMTP id 2C47840143 for ; Sat, 9 Oct 2021 04:03:39 +0200 (CEST) Received: by mail-pl1-f182.google.com with SMTP id y1so7231577plk.10 for ; Fri, 08 Oct 2021 19:03:39 -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=bZyRqz27s2zSrR9mhbPPno9TG907F+N2NgL3qlx3v8Q=; b=pQKVoH185rw1l1gsQUXV/K1suFo64EAZJPVbF1OPUEvNS7TFObhewYFPaaY0QbDC3c cywSAzJ1xFClbrDCWm4mXiJ467o89UNw0PLbwsJGIzovphxKLKBrDIVxZ8firA6M135G qzBVFOE1SNimYhLYVnXgpu41Sh9HoqQ36x7YknUs/FV0W8P2qPAUquE8lhfzuuIukr7x PIT3+4sMscd0zgKAfdXMNdOus6IGp7m6PSsERuWoUSdQUxVqbgrIPAiHCUwOdaiUKVlV LXdeiNNg2oFBYisuDT0w7fiTRVS97Ihp/lcxdr9m/Q9ciEerJjrfpRsgEPIXqZx9Eypu tMzQ== 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=bZyRqz27s2zSrR9mhbPPno9TG907F+N2NgL3qlx3v8Q=; b=IE8m6UkCXUF9XaYbg4+nMeSq2KnWDIkyIwDCQ/dKqjb1hm/sbxqJTrrJSGjwp0V6jv 99btnEkVEUESJ1ABL7ZpMzz9EmXmxQN4sZzpYm8ej3uSfyTN+YRWALvb+CxQhFN+y9q2 0D2hJQHSjXF5oEwz0A/JIbSaNPo/A/WumOu3Zc9hl5+AwB0ZoSMxPtB9M/ZNCPwwJ949 2DUjGyAkyPAGUXPSh2Gugq3fvPApONeLST/qIHa6dclOB3oqjfURecQFKO4EfsyAN/OR W54UW/Ak9V4JrSetWQZI85TiKtCdsQ6A6guO3i1XCKL+y04rlAvvA0AfkOmjcOyRbr4M 1rDQ== X-Gm-Message-State: AOAM532fIjGkjSTkhyWF7b/iXkDMAi33OaMYuAiSuRrE2X1LnsGb1ApO 4k4CDTuuHz4nYfGu825iAUSRtg== X-Google-Smtp-Source: ABdhPJz6+KKtWwmgJ9qRldV7iDPflRBBGzksfSRUH6Qj0XwfgVo9iqJq8ImdZHNj/ZXYbqhFj8Mwuw== X-Received: by 2002:a17:902:7b98:b0:138:c171:c1af with SMTP id w24-20020a1709027b9800b00138c171c1afmr12445122pll.70.1633745018234; Fri, 08 Oct 2021 19:03:38 -0700 (PDT) Received: from hermes.local (204-195-33-123.wavecable.com. [204.195.33.123]) by smtp.gmail.com with ESMTPSA id 127sm523185pfw.10.2021.10.08.19.03.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Oct 2021 19:03:37 -0700 (PDT) Date: Fri, 8 Oct 2021 19:03:35 -0700 From: Stephen Hemminger To: Ferruh Yigit Cc: Elad Nachman , dev@dpdk.org, stable@dpdk.org, Igor Ryzhov , Eric Christian Message-ID: <20211008190335.1fdc8f4a@hermes.local> In-Reply-To: <20211008235830.127167-1-ferruh.yigit@intel.com> References: <20211008235830.127167-1-ferruh.yigit@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] kni: restrict bifurcated device support 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 Sender: "dev" On Sat, 9 Oct 2021 00:58:30 +0100 Ferruh Yigit wrote: > To enable bifurcated device support, rtnl_lock is released before calling > userspace callbacks and asynchronous requests are enabled. > > But these changes caused more issues, like bug #809, #816. To reduce the > scope of the problems, the bifurcated device support related changes are > only enabled when it is requested explicitly with new 'enable_bifurcated' > module parameter. > And bifurcated device support is disabled by default. > > So the bifurcated device related problems are isolated and they can be > fixed without impacting all use cases. > > Bugzilla ID: 816 > Fixes: 631217c76135 ("kni: fix kernel deadlock with bifurcated device") > Cc: stable@dpdk.org > > Signed-off-by: Ferruh Yigit Calling userspace with semaphore held is still risky and buggy. There is no guarantee that the userspace DPDK application will be well behaved. And if it is not, the spinning holding RTNL would break any other network management functions in the kernel. These are the kind of problems that make me think it there should be a big "DO NOT USE THIS" onto KNI. Maybe make it print a big nasty message (see kernel VFIO without IOMMU description) or mark kernel as tainted?? See: https://fedoraproject.org/wiki/KernelStagingPolicy Something like: diff --git a/kernel/linux/kni/kni_net.c b/kernel/linux/kni/kni_net.c index 611719b5ee27..d47fc6133cbe 100644 --- a/kernel/linux/kni/kni_net.c +++ b/kernel/linux/kni/kni_net.c @@ -838,6 +838,14 @@ kni_net_init(struct net_device *dev) dev->header_ops = &kni_net_header_ops; dev->ethtool_ops = &kni_net_ethtool_ops; dev->watchdog_timeo = WD_TIMEOUT; + + /* + * KNI is unsafe since it requires calling userspace to do + * control operations. And the overall quality according to + * kernel standards is the same as devices in staging. + */ + add_taint(TAINT_CRAP, LOCKDEP_STILL_OK); + netdev_warn(dev, "Adding kernel taint for KNI because it is not safe\n"); } void