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 19A82A0547; Tue, 15 Nov 2022 08:47:33 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B64FD40DFD; Tue, 15 Nov 2022 08:47:32 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 9CB2340150 for ; Tue, 15 Nov 2022 08:47:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668498449; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DBsII39AA9u+LI9lF/l8kAgqcgwPkN8mBdz4qTmy0/g=; b=EgdAymOVEfoFmIZAf1w3seJYs8T1GQQeON+t5T0a2y52KmSuoKjaXtgPUD51aTRpziq9TM FTlx+wV8yDEu15/lStKAh55gVqKSCA3HeQ837r5kbNG8WwTPBUV3ds38q6EluwWeL+hVVi MG+sTObI1WEUfx4QBgYdS9aor7kut70= Received: from mail-pl1-f199.google.com (mail-pl1-f199.google.com [209.85.214.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-12-8xodU_m0MUewC5gdaqbmjQ-1; Tue, 15 Nov 2022 02:47:28 -0500 X-MC-Unique: 8xodU_m0MUewC5gdaqbmjQ-1 Received: by mail-pl1-f199.google.com with SMTP id e13-20020a17090301cd00b001871e6f8714so10865799plh.14 for ; Mon, 14 Nov 2022 23:47:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=DBsII39AA9u+LI9lF/l8kAgqcgwPkN8mBdz4qTmy0/g=; b=TSuefQtP4CsDcFKrGCia5VruUQPTtHSDlHH6dbaOPp+kxePBD2YAibHTbsGZjvZJBf AQmiY3ull67hWSWowKEf5ONmBJbbx3BxQYbE0nAqNfMUtgr/vTL4ymCac5ydQWaZf3ke VcrLGpfN2QjcuiQyWmAMRME+bj2UYIRbKNhkKPhvC0vRIE5YtdjEc56XG1P/mwzLDxOE p86RNAgNDvGPw6vr3zyFmi8+vmNwWWsTQIw4JiYEjisb15CYmXiFoy5GjTOvFyRahGJN OXieCnDO6T2yNtECnNDkDSmyV0lRSCDBgK+fxJWm4l38mXMYn70anmWpy/pdNJJvLQ9T bsxg== X-Gm-Message-State: ANoB5pkoVymVhRaqviXbIa/mR2mWrpnqoEhZiSW2d2PQsGt3tvsBj7hg PHFsjrXaWo/AKmv21fxkKWsLn+MwBuedMnCDqP5MZiVgduabnFUlwQPkoERzuV9ftEgyhQPYbMs ftpxiZy0nnXp0WvjzzVU= X-Received: by 2002:a17:902:d64f:b0:188:beef:b68f with SMTP id y15-20020a170902d64f00b00188beefb68fmr2670181plh.172.1668498447357; Mon, 14 Nov 2022 23:47:27 -0800 (PST) X-Google-Smtp-Source: AA0mqf4VHz+tlulPjXmwsDue2M0U+bcNp7/30mGl1SS2HwKyClH7jYCpBIuFdRo/F6H7Xm+mA+NQqpXYf9ERccp0jFs= X-Received: by 2002:a17:902:d64f:b0:188:beef:b68f with SMTP id y15-20020a170902d64f00b00188beefb68fmr2670168plh.172.1668498447041; Mon, 14 Nov 2022 23:47:27 -0800 (PST) MIME-Version: 1.0 References: <20221114071439.38902-1-changfengnan@bytedance.com> In-Reply-To: From: David Marchand Date: Tue, 15 Nov 2022 08:47:15 +0100 Message-ID: Subject: Re: [External] Re: [PATCH] mempool: fix rte_mempool_avail_count may segment fault when used in multiprocess To: Fengnan Chang , olivier.matz@6wind.com, andrew.rybchenko@oktetlabs.ru Cc: dev@dpdk.org, =?UTF-8?Q?Morten_Br=C3=B8rup?= X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Tue, Nov 15, 2022 at 2:51 AM Fengnan Chang wrote: > > David Marchand =E4=BA=8E2022=E5=B9=B411=E6=9C= =8815=E6=97=A5=E5=91=A8=E4=BA=8C 04:44=E5=86=99=E9=81=93=EF=BC=9A > > > > On Mon, Nov 14, 2022 at 9:13 AM changfengnan wrote: > > > > > > rte_mempool_create put tailq entry into rte_mempool_tailq list before > > > populate, and pool_data set when populate. So in multi process, if > > > process A create mempool, and process B can get mempool through > > > rte_mempool_lookup before pool_data set, if B call rte_mempool_lookup= , > > > it will cause segment fault. > > > > I fail to see how pool_data impacts rte_mempool_lookup. > > Something is fishy about this commitlog. > > oh, it's my fault about this commit. correct: if B can get mempool throug= h > rte_mempool_lookup before pool_data set, and call rte_mempool_avail_count= , > it will cause segment fault. Ok, now it makes more sense :-). > > > > > > > > Fix this by put tailq entry into rte_mempool_tailq after populate. > > > > Moving tailq manipulation to rte_mempool_create only, is probably incor= rect. > > An application is allowed to call rte_mempool_create_empty() and > > rte_mempool_populate(). > > > > I did not look in depth, but It is likely the reason why testpmd (as > > run with devtools/test-null.sh) won't pass anymore. > > The CI reported this issue in various envs. > > > > We can't take this patch. > > Yeah, this version makes CI fail. > I didn't notice rte_mempool_create_empty will called directly before, may= be > add a new flag bit to indicate when to put tailq entry into rte_mempool_t= ailq > list is a better way. If no better idea, I'll send a new version. I don't think we need an other flag. Can we "publish" the mempool at the mempool_ops_alloc_once stage? > > > > > > > > > > > Signed-off-by: changfengnan > > > > Please use your real name. > > It's my real name. Sorry, I meant your full name, like Fengnan Chang --=20 David Marchand