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 72515A0547; Tue, 15 Nov 2022 09:29:22 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 15CE240DFD; Tue, 15 Nov 2022 09:29:22 +0100 (CET) Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) by mails.dpdk.org (Postfix) with ESMTP id EEB3D40150 for ; Tue, 15 Nov 2022 09:29:20 +0100 (CET) Received: by mail-wm1-f47.google.com with SMTP id ja4-20020a05600c556400b003cf6e77f89cso777299wmb.0 for ; Tue, 15 Nov 2022 00:29:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=1NDDgSHWbVmgn1Y6UzlN7CGTceW6Rv0jpv6WOhugrwQ=; b=XkdRPfkEkpKlLbeZDTKbgVy4g6iYPJhWLpjQmkiRlJGPaw4bDLTPLB1F6FvQgGR/Dz MSwvqfkmNMy0Eh+697VnTQtRaV+6cd62TbDvkUv/N3qkZv1euJdMT/6ZYkOhrGPKYovj kv939SfDG6eI7hsjVF8pFcfIyEZcWSLS2kiLtMymDsl+FhMewAo76W/Amq1KNh7j947i uS4zaaq61hwZcUrwZe1SHdPLG7B/JIN8jAk5CgZrFUSSlLxJDQhTOdwSua9RFwTVe84Z SFueM6z3O8PrMTvVrsLOiO8QZl01hftycp+S+FqbdWt0k0v93VIVIBMLJFHNMcKiK77j bwMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=1NDDgSHWbVmgn1Y6UzlN7CGTceW6Rv0jpv6WOhugrwQ=; b=qwwJpLBD+sxnwubFtr6XGGRiC1BEoKesN4HLWiP8DXg2yu8HWENg2dCvVuCRkva/yH Gu0L9epaO9UA8uXjvHPJ860SjawqmsVHFgprIYP3zV8b3aD8d5Kspwq0zDfZbgfnJRkP Xd+8t6mU4ho940JYS9FsOG6zeHv/70YAs4Q1akMznBlLcPBzEXoKcYOAXwEAZ/bEfuzT 1Jsx+IQ04AqeyFGNEFtV3Ff2hQle1LwxH4MUabK2U0x57mnMSTum2plrxXIRv3TO1GAm P1jqNrZ5fNO3TJ2gEYamg0MexJpcfMp8OnEQLFNftLgyB9edu61cTeRPrq5wKBt+2w5i ewuA== X-Gm-Message-State: ANoB5plRT+3WFSZ2mBaPpzI5mQ551i/cPg4fRF1q7tGi5qVydfKJEl2t ApVQAMlwt7MWi5NZbSgRH5fLgslJX26asg== X-Google-Smtp-Source: AA0mqf51NrR8L77zd5jxY/oazuLp4WLR8OqXLLK57vQyHz+cFQ7EDktvQR0u2++H4leWaseHhNzPWQ== X-Received: by 2002:a05:600c:4fd6:b0:3cf:cab4:a42b with SMTP id o22-20020a05600c4fd600b003cfcab4a42bmr21402wmq.36.1668500960660; Tue, 15 Nov 2022 00:29:20 -0800 (PST) Received: from 6wind.com ([2a01:e0a:5ac:6460:c065:401d:87eb:9b25]) by smtp.gmail.com with ESMTPSA id z16-20020a05600c0a1000b003cfe1dcd354sm4836249wmp.27.2022.11.15.00.29.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Nov 2022 00:29:19 -0800 (PST) Date: Tue, 15 Nov 2022 09:29:19 +0100 From: Olivier Matz To: David Marchand Cc: Fengnan Chang , andrew.rybchenko@oktetlabs.ru, dev@dpdk.org, Morten =?iso-8859-1?Q?Br=F8rup?= Subject: Re: [External] Re: [PATCH] mempool: fix rte_mempool_avail_count may segment fault when used in multiprocess Message-ID: References: <20221114071439.38902-1-changfengnan@bytedance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 Hi, On Tue, Nov 15, 2022 at 08:47:15AM +0100, David Marchand wrote: > On Tue, Nov 15, 2022 at 2:51 AM Fengnan Chang > wrote: > > > > David Marchand 于2022年11月15日周二 04:44写道： > > > > > > 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 through > > 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 incorrect. > > > 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, maybe > > add a new flag bit to indicate when to put tailq entry into rte_mempool_tailq > > 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? The mempool_ops_alloc_once() seems it is the proper place, yes. Alternatively, I suppose this issue can be fixed in the secondary application: - it can wait that the flag RTE_MEMPOOL_F_POOL_CREATED is present before using the mempool. - or it can wait the RTE_MEMPOOL_EVENT_READY - or it can wait that the whole initialization of the primary application is finished by another mean (a sort of lock). I don't know the exact use case, but to me, it looks sane to do that, it would protect from other similar issues. Olivier > > > > > > > > > > > > > > > > > > Signed-off-by: changfengnan > > > > > > Please use your real name. > > > > It's my real name. > > Sorry, I meant your full name, like Fengnan Chang > > > -- > David Marchand >