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 45E2B464F2; Thu, 3 Apr 2025 10:12:22 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0DA4C4060C; Thu, 3 Apr 2025 10:12:22 +0200 (CEST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by mails.dpdk.org (Postfix) with ESMTP id 1D5F14060A for ; Thu, 3 Apr 2025 10:12:19 +0200 (CEST) Received: from mail.maildlp.com (unknown [172.19.88.194]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4ZSvW428QTzvWrV; Thu, 3 Apr 2025 16:08:16 +0800 (CST) Received: from kwepemo500011.china.huawei.com (unknown [7.202.195.194]) by mail.maildlp.com (Postfix) with ESMTPS id 8DA1E140383; Thu, 3 Apr 2025 16:12:16 +0800 (CST) Received: from [10.67.121.193] (10.67.121.193) by kwepemo500011.china.huawei.com (7.202.195.194) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 3 Apr 2025 16:12:15 +0800 Message-ID: Date: Thu, 3 Apr 2025 16:12:15 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/3] eal: fix unckeck pipe To: =?UTF-8?Q?Morten_Br=C3=B8rup?= , CC: , , , , , , , , Harry van Haaren References: <20250321040316.104126-1-huangdengdui@huawei.com> <20250402122454.2148612-1-huangdengdui@huawei.com> <20250402122454.2148612-3-huangdengdui@huawei.com> <98CBD80474FA8B44BF855DF32C47DC35E9FB8D@smartserver.smartshare.dk> Content-Language: en-US From: huangdengdui In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9FB8D@smartserver.smartshare.dk> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.121.193] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To kwepemo500011.china.huawei.com (7.202.195.194) 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 2025/4/2 22:45, Morten Brørup wrote: >> From: Dengdui Huang [mailto:huangdengdui@huawei.com] >> Sent: Wednesday, 2 April 2025 14.25 >> >> The communication pipe may be unavailable, for example, >> when the lcore role is ROLE_OFF or ROLE_NON_EAL. >> So check whether the pipe is available before using it. >> >> Fixes: a95d70547c57 ("eal: factorize lcore main loop") >> Cc: stable@dpdk.org >> >> Signed-off-by: Dengdui Huang >> --- >> lib/eal/unix/eal_unix_thread.c | 3 +++ >> lib/eal/windows/eal_thread.c | 3 +++ >> 2 files changed, 6 insertions(+) >> >> diff --git a/lib/eal/unix/eal_unix_thread.c >> b/lib/eal/unix/eal_unix_thread.c >> index ef6cbff0ee..103571cabf 100644 >> --- a/lib/eal/unix/eal_unix_thread.c >> +++ b/lib/eal/unix/eal_unix_thread.c >> @@ -17,6 +17,9 @@ eal_thread_wake_worker(unsigned int worker_id) >> char c = 0; >> int n; >> >> + if (m2w == 0 || w2m == 0) >> + return -EINVAL; >> + >> do { >> n = write(m2w, &c, 1); >> } while (n == 0 || (n < 0 && errno == EINTR)); >> diff --git a/lib/eal/windows/eal_thread.c >> b/lib/eal/windows/eal_thread.c >> index 9e3df200b9..82bb974868 100644 >> --- a/lib/eal/windows/eal_thread.c >> +++ b/lib/eal/windows/eal_thread.c >> @@ -24,6 +24,9 @@ eal_thread_wake_worker(unsigned int worker_id) >> char c = 0; >> int n; >> >> + if (m2w == 0 || w2m == 0) >> + return -EINVAL; >> + >> do { >> n = _write(m2w, &c, 1); >> } while (n == 0 || (n < 0 && errno == EINTR)); >> -- >> 2.33.0 > > This internal function eal_thread_wake_worker() is only called from rte_eal_remote_launch(). > It would be better to check the lcore role there. > Is it better to check lcore roles in rte_eal_remote_launch() instead? Only Role_RTE and Role_SERVICE lcore can be woken up through rte_eal_remote_launch(). > References: > https://elixir.bootlin.com/dpdk/v25.03-rc2/A/ident/eal_thread_wake_worker > https://elixir.bootlin.com/dpdk/v25.03-rc2/source/lib/eal/common/eal_common_launch.c#L52 > > Furthermore, in theory, file descriptor 0 is a valid file descriptor; if "stdin" has been closed, a newly opened file (or pipe) may be assigned file descriptor 0. > >