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 949E1A00C3; Fri, 13 May 2022 03:57:34 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3320440E64; Fri, 13 May 2022 03:57:34 +0200 (CEST) Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com [209.85.215.171]) by mails.dpdk.org (Postfix) with ESMTP id 1D7C140DDE for ; Fri, 13 May 2022 03:57:32 +0200 (CEST) Received: by mail-pg1-f171.google.com with SMTP id x12so6175695pgj.7 for ; Thu, 12 May 2022 18:57:32 -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=QuFA0VOr1UPsYZ4zPfAE2reZWQkVB/VaG26aqb5n47Q=; b=OtEBGn9ASvsoDwsKBFor9oMT3Z1H0Cgycc4ROZmD5912EgZdVBATGjpEmZhGKkfWL8 EZ3q74W1dzticHpjYOVtIhVBkhaK4d0429TNVBD7rON+P8R4XCydYIYKyBeDNxPIDUqV +Hs5T1YpZ9LSRsHhdpbpT/czqV+wO2fTlt4gAedeUQk8m/7Swnd8dDGBByNUfU90ZMvY jiHxoplNyCwkXf7i74nK+eN5DTYYq+H4j4Zdoita9QQ0BGBQyX6HRsBGJ+TNHb3QGMuu T89AK4/jjJ2u5+p+Swfx1bCdojdBUMtGBDt55PKMe5lfsGfleC6eywWaz9Z83LGsR2zO +fiQ== 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=QuFA0VOr1UPsYZ4zPfAE2reZWQkVB/VaG26aqb5n47Q=; b=wgVilPiRRRN84yeTrYWuD4xloq0DOPC+fMzsyfZWus9vYgD57vdR/jRJFiKfAgJ+BB q3aLeOkMKWUcv4r1L475VLg9ZpRgGg07MUT914L749Ecsflypp8JLc10tFiw+nNqc+Tl /qwARjuzmYeNPe/bTXviGnDM/u6ZC2Xw+aFfJUwRIGAyc0noYl8FHWwDRLX94NrtzV0Q BqZQlMUMEEnxb5XF9SpvQXQPSQR4sdvU4VB3zBeiTMuzhIlAMd7rI4kRDLVI+Du+9al8 gnAYd6yI2N2ODjUxgU9u5Vdz/x2I7Az29NLpzkz8pAz7MtxN0UeG3DrxRMrBxtsFDL2r FDGQ== X-Gm-Message-State: AOAM531df4L4hYqapOHmL9P5gxU2Knb1NAMmfyadEjjZ1hZ9xRjm6kha lL/43yC9mZfSyb4f4aPaJ5Mdjg== X-Google-Smtp-Source: ABdhPJxCKRCbG7AIz+PGCcfrec6HuZob3fdy3GYv1k6zbQGL5pqkFU7/YDDTuIueBDxHE4JKvsjQtg== X-Received: by 2002:a63:8943:0:b0:3aa:f1ce:4f24 with SMTP id v64-20020a638943000000b003aaf1ce4f24mr2031901pgd.34.1652407052065; Thu, 12 May 2022 18:57:32 -0700 (PDT) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id a3-20020a170902710300b0015e8d4eb22esm552372pll.120.2022.05.12.18.57.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 May 2022 18:57:31 -0700 (PDT) Date: Thu, 12 May 2022 18:57:29 -0700 From: Stephen Hemminger To: "Zhang, Ke1X" Cc: "Li, Xiaoyun" , "Wu, Jingjing" , "Xing, Beilei" , "dev@dpdk.org" Subject: Re: [PATCH v5] fix mbuf release function point corrupt in multi-process Message-ID: <20220512185729.6886f826@hermes.local> In-Reply-To: References: <20220510025428.110325-1-ke1x.zhang@intel.com> <20220512055719.181652-1-ke1x.zhang@intel.com> <20220512102655.35af90a9@hermes.local> 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 Fri, 13 May 2022 01:34:02 +0000 "Zhang, Ke1X" wrote: > > -----Original Message----- > > From: Stephen Hemminger > > Sent: Friday, May 13, 2022 1:27 AM > > To: Zhang, Ke1X > > Cc: Li, Xiaoyun ; Wu, Jingjing ; > > Xing, Beilei ; dev@dpdk.org > > Subject: Re: [PATCH v5] fix mbuf release function point corrupt in multi- > > process > > > > On Thu, 12 May 2022 05:57:19 +0000 > > Ke Zhang wrote: > > > > > > > > -static const struct iavf_rxq_ops def_rxq_ops = { > > > - .release_mbufs = release_rxq_mbufs, > > > +static > > > +struct iavf_rxq_ops iavf_rxq_release_mbufs_ops[] = { > > > + [IAVF_REL_MBUFS_DEFAULT].release_mbufs = release_rxq_mbufs, > > > + [IAVF_REL_MBUFS_SSE_VEC].release_mbufs = > > iavf_rx_queue_release_mbufs_sse, > > > }; > > > > > > -static const struct iavf_txq_ops def_txq_ops = { > > > - .release_mbufs = release_txq_mbufs, > > > +static > > > +struct iavf_txq_ops iavf_txq_release_mbufs_ops[] = { > > > + [IAVF_REL_MBUFS_DEFAULT].release_mbufs = release_txq_mbufs, > > > + [IAVF_REL_MBUFS_SSE_VEC].release_mbufs = > > iavf_tx_queue_release_mbufs_sse, > > > + [IAVF_REL_MBUFS_AVX512_VEC].release_mbufs = > > iavf_tx_queue_release_mbufs_avx512, > > > }; > > > > Did you have to take const off of these? > > Thanks for your comments, I check the other code like linux kernel , I found there are no const for the function pointer, like: > > static struct pci_driver ice_driver = { > .name = KBUILD_MODNAME, > .id_table = ice_pci_tbl, > .probe = ice_probe, > .remove = ice_remove, > #ifdef CONFIG_PM > .driver.pm = &ice_pm_ops, > #endif /* CONFIG_PM */ > .shutdown = ice_shutdown, > #ifndef STATIC_QOS_CFG_SUPPORT > .sriov_configure = ice_sriov_configure, > #endif /* !STATIC_QOS_CFG_SUPPORT */ > #ifdef HAVE_RHEL7_PCI_DRIVER_RH > .pci_driver_rh = &ice_driver_rh, > #endif /* HAVE_RHEL7_PCI_DRIVER_RH */ > .err_handler = &ice_pci_err_handler > }; > > So I don't add the const. > This is not the kernel! The kernel pci device has other reasons it can't be const. This is because the Linux kernel pci_driver structure gets linked into the list of PCI devices. The kernel should be splitting the device object (pci_driver) from the functions by introducing a new pci_driver_ops. But this would require lots of extra work; the kernel hardening project may get to it. As a general rule: any table with function pointers should be const for security reasons. The DPDK has less security requirements than the kernel and less security testing, but developers should try to avoid issues if possible.